Subject: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 3

From: Todd Herr <[email-masked]>
Date: Thu, 27 Jan 2022 18:02:33 -0500

Greetings.

I've taken your comments under consideration, have incorporated many of
them, and have made a few other edits to boot.

The following text is the latest proposed text for this section of the A/S,
and will also be added to Ticket 54.

=========================== cut here =========================

5. Confidentiality and Authentication with SMTP

SMTP is specified without embedded mechanisms for authentication or
confidentiality; its traffic is therefore “in the clear”. Years of
operational experience have shown that such transmission exposes the
message to easy compromise, including wiretapping and spoofing. To mitigate
these risks, operation of SMTP has evolved over the years so that it is
used with the benefit of Transport Layer Security (TLS - RFC8446) to
provide both confidentiality and authentication in the transmission of
messages. This section discusses those topics and their most common uses.

It is important that the reader understand what is meant by the terms
“Authentication” and “Confidentiality”, and for that we will borrow
directly from RFC8446.

   -

   Authentication is the process of establishing the identity of one or
   more of the endpoints of a communication channel. TLS only requires
   authentication of the server side of the communication channel;
   authentication of the client side is optional.
   -

   The term “confidentiality” describes a state where the data (i.e., the
   message) is transmitted in a way that it is only visible to the endpoints
   of a communication channel.

It is not uncommon for implementers to use the term “encryption” to mean
“confidentiality”, but this is not quite correct. Rather, encryption using
TLS is the current method by which confidentiality is achieved with SMTP,
but that does not mean that future methods might not be developed.

Note: With typical email use of TLS, authentication only is performed for
the target receiving server and is not done for the sending client. That
is, it serves to validate that the connection has been made to the intended
server, but does not validate who initiated it.

5.1 Optional Confidentiality

The most common implementation of message confidentiality is what’s known
as “opportunistic TLS”, which is frequently referred to as “opportunistic
encryption”. With this method, a receiving server announces in its greeting
that it is capable of supporting TLS encryption through the presence of the
“STARTTLS” keyword. The sending client then attempts to negotiate an
encrypted connection, and if successful, transmits the message in encrypted
form; if negotiation fails, the client falls back to sending the message in
clear text.

Opportunistic TLS is confidentiality without authentication, because no
effort is made to authenticate the receiving server, and it is optional
confidentiality due to the ability to fall back to transmission in the
clear if a secure connection cannot be established. That said, most modern
implementations of SMTP support this method, especially at the largest
mailbox providers, and so the vast majority of email traffic is encrypted
during its time transiting from the client to the server.

Note: While TLS provides protection while the message is in transit, there
is no guarantee that the message will be stored in encrypted fashion at its
destination. In fact, storage in plain text should be expected!

5.2 Required Confidentiality, with Receiving Server Authentication

Two protocols exist that move message confidentiality from optional to
required (with conditions as noted below) - MTA-STS [RFC8461] and DANE for
SMTP [RFC7672]. While they differ in their implementation details,
receiving servers relying on either protocol are stating that they only
accept mail if the transmission can be encrypted with TLS, and a failure to
negotiate a secure connection MUST result in the sending client refusing to
transmit the message. Support for both protocols is increasing, but is not
yet mandatory.

These two protocols differ from Opportunistic TLS in that they require
receiving server authentication and there is no fallback to sending in the
clear if negotiation of an encrypted connection fails.

Note: Both protocols mentioned in this section rely not only on the
receiving server but also the sending client supporting the protocol
intended to be used. If the sending client does not implement or understand
the protocol requested by the receiving server, the sending client will use
Opportunistic TLS or clear-text to transmit the message.

5.3 Message-Level Authentication

Protocols exist to allow for authentication of different identities
associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A
third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow for
validation of the domain in the visible From header, and a fourth, ARC
[RFC8617], provides a way for each hop to record results of authentication
checks performed at that hop.

All of these are outside the scope of this document, as they are outside
the scope of SMTP. They deal with validating the authorized usage of one or
more domains in an email message, and not with establishing the identity of
the receiving server.

5.4 SMTP Authentication

SMTP Authentication, which is often abbreviated as SMTP AUTH, is an
extension to SMTP. While its name might suggest that it would be within
scope for this section of the Applicability Statement, nothing could be
further from the truth.

SMTP AUTH defines a method for a client to identify itself to a Message
Submission Agent (MSA) when presenting a message for transmission, usually
using port 587 rather than the traditional port 25. The most common
implementation of SMTP AUTH is for a person to present a username and
password to their mailbox provider’s outbound SMTP server when configuring
their MUA for sending mail.

5.5 Message-Level Confidentiality

Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to allow for
message confidentiality outside of the operation of SMTP. That is to say,
using these protocols results in encryption of the message prior to its
being submitted to the SMTP communications channel, and decryption of the
message is the responsibility of the message recipient. There are numerous
implementations of these protocols, too many to list here. As they operate
fully independent of SMTP, they are out of scope for this document.
=========================== cut here =========================

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jan 2022 15:45:28 -0800

On 1/27/2022 3:02 PM, Todd Herr wrote:
...
> Note: With typical email use of TLS, authentication only is performed 
> for the target receiving server and is not done for the sending client. 
> That is, it serves to validate that the connection has been made to the 
> intended server, but does not validate who initiated it.

I think this has my wording and I now see the first sentence might be 
misinterpreted, since it isn't clear who is authenticating whom.  I suggest:

Note: With typical email use of TLS, authentication only is performed by 
the sending client of the target receiving server. That is, it serves to 
validate that the connection has been made to the intended server, but 
does not validate who initiated it.

> 5.1 Optional Confidentiality
...
> 
> Note: While TLS provides protection while the message is in transit, 
> there is no guarantee that the message will be stored in encrypted 
> fashion at its destination. In fact, storage in plain text should be 
> expected!

To respond to the significant concern that was raised that the reader 
properly understand that this is hop-by-hop wire encryption and is not 
end-to-end, I suggest:

Note: While TLS provides protection while the message is in transit for 
a single SMTP connection, a message that is encrypted for one SMTP hop 
might not be encrypted on the next hop and it might not be encrypted 
within MTAs relaying the message or at its destination. In fact, storage 
in plain text should be expected!

> required (with conditions as noted below) - MTA-STS [RFC8461] and DANE 
> for SMTP [RFC7672]. While they differ in their implementation details, 
> accept mail if the transmission can be encrypted with TLS, and a failure 
> to negotiate a secure connection MUST result in the sending client 
> refusing to transmit the message. Support for both protocols is 
> increasing, but is not yet mandatory.
> 
> receiving server authentication and there is no fallback to sending in 
> the clear if negotiation of an encrypted connection fails.
> 
> intended to be used. If the sending client does not implement or 
> understand the protocol requested by the receiving server, the sending 
> client will use Opportunistic TLS or clear-text to transmit the message.
> 
> [RFC8617], provides a way for each hop to record results of 
> authentication checks performed at that hop.
> 
> the scope of SMTP. They deal with validating the authorized usage of one 
> or more domains in an email message, and not with establishing the 
> identity of the receiving server.
> 
> 5.4 SMTP Authentication
> 

I suspect many things could be further for the truth...  So perhaps some 
milder and more bording wording, such as:

    It doesn't.

> Submission Agent (MSA) when presenting a message for transmission, 
> usually using port 587 rather than the traditional port 25. The most 
> common implementation of SMTP AUTH is for a person to present a username 
> and password to their mailbox provider’s outbound SMTP server when 
> configuring their MUA for sending mail.
> 

I'm not offering wording, but it might be worth using this section to 
introduce the terms Channel Security versus Object Security.  TLS is a 
channel-based mechanism. So is SPF.   S/MIME, OpenPGP, DKIM, DMARC and 
ARC are all Object based.  The simple description I'm used to, about the 
difference, is that Channel-based protects whatever bits go over the 
channel, without concern for the content, where Object-based is attached 
to the object and is not concerned with details of the Channel.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Jan 2022 11:37:25 -0500

Todd,

I think this is moving in the right direction.  However...

(1) Much of this seems to be a tutorial rather than clear
statements about things that people should or should not do.  I
wonder if such a tutorial reasonably falls within the scope of
EMAILCORE and, more specifically, if we should be encouraging
the Security ADs to make such a tutorial part of the LAMPS
effort that is working on draft-ietf-lamps-e2e-mail-guidance.
For similar reasons that are less related to the LAMPS work, it
is not clear to me why an Applicability Statement needs to spend
time discussing what it is not going to discuss.

Almost independent of that concern...

(2) If you are going to mention S/MIME and OpenPGP at all, you
should add that each can provide authentication as well as, or
in addition to confidentiality. In particular, given a few
assumptions about the ability of senders to manage keys (a much
broader issue and heavily dependent on the type of senders),
they provide much stronger authentication and message content
integrity protection than any of the other methods you mention.
Probably also worth mentioning that there are other mechanisms
(not standardized by the IETF) in that space and they do not
provide confidentiality for the SMTP envelope and, in general,
not even the message headers.

(3) Having read through the text several times, it is not likely
that a reader who is not very clear about all of these
mechanisms already will be able to figure out what is being
protected from either an authentication or confidentiality
standpoint.  At one extreme, S/MIME, OpenPGP, and friends
provide strong and sender to receiver authentication, integrity
protection, and/or confidentiality, but only for some or all of
the message content.   Other methods you describe may provide
greater protection for message headers and all or part of the
envelope information, but require that anyone wanting to trust
that confidentiality or authenticity have great trust in the
operators, servers, and systems that handle the message when it
is not actually on the wire.  IMO, failure to make those
distinctions clear significantly weakens the presentation and
may even turn it from "helpful" into "part of the problem and
dangerous".  The text you quoted takes a small step in the
direction I'm encouraging by pointing out that TLS often does
not involve authentication of the client, only the server (and,
by implication, does not authenticate the sender at all, only
some of the machines that handle the message).  Perhaps a chart
would be helpful.

best,
   john

--On Thursday, January 27, 2022 18:02 -0500 Todd Herr
<todd.herr=[email-masked]> wrote:

> Greetings.
> 
> I've taken your comments under consideration, have
> incorporated many of them, and have made a few other edits to
> boot.
> 
> The following text is the latest proposed text for this
> section of the A/S, and will also be added to Ticket 54.
> 
> SMTP is specified without embedded mechanisms for
> authentication or confidentiality; its traffic is therefore
> "in the clear". Years of operational experience have shown
> that such transmission exposes the message to easy compromise,
> including wiretapping and spoofing. To mitigate these risks,
> operation of SMTP has evolved over the years so that it is
> used with the benefit of Transport Layer Security (TLS -
> RFC8446) to provide both confidentiality and authentication in
> the transmission of messages. This section discusses those
> topics and their most common uses.
> 
> It is important that the reader understand what is meant by
> the terms "Authentication" and "Confidentiality", and
> for that we will borrow directly from RFC8446.
> 
>    -
> 
>    Authentication is the process of establishing the identity
> of one or    more of the endpoints of a communication channel.
> TLS only requires    authentication of the server side of the
> communication channel;    authentication of the client side is
> optional.
>    -
> 
>    The term "confidentiality" describes a state where the
> data (i.e., the    message) is transmitted in a way that it is
> only visible to the endpoints    of a communication channel.
> 
> It is not uncommon for implementers to use the term
> "encryption" to mean "confidentiality", but this is
> not quite correct. Rather, encryption using TLS is the current
> method by which confidentiality is achieved with SMTP, but
> that does not mean that future methods might not be developed.
> 
> Note: With typical email use of TLS, authentication only is
> performed for the target receiving server and is not done for
> the sending client. That is, it serves to validate that the
> connection has been made to the intended server, but does not
> validate who initiated it.
> 
> The most common implementation of message confidentiality is
> what's known as "opportunistic TLS", which is frequently
> referred to as "opportunistic encryption". With this
> method, a receiving server announces in its greeting that it
> is capable of supporting TLS encryption through the presence
> of the "STARTTLS" keyword. The sending client then
> attempts to negotiate an encrypted connection, and if
> successful, transmits the message in encrypted form; if
> negotiation fails, the client falls back to sending the
> message in clear text.
> 
> Opportunistic TLS is confidentiality without authentication,
> because no effort is made to authenticate the receiving
> server, and it is optional confidentiality due to the ability
> to fall back to transmission in the clear if a secure
> connection cannot be established. That said, most modern
> implementations of SMTP support this method, especially at the
> largest mailbox providers, and so the vast majority of email
> traffic is encrypted during its time transiting from the
> client to the server.
> 
> Note: While TLS provides protection while the message is in
> transit, there is no guarantee that the message will be stored
> in encrypted fashion at its destination. In fact, storage in
> plain text should be expected!
> 
> Two protocols exist that move message confidentiality from
> optional to required (with conditions as noted below) -
> MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they
> differ in their implementation details, receiving servers
> relying on either protocol are stating that they only accept
> mail if the transmission can be encrypted with TLS, and a
> failure to negotiate a secure connection MUST result in the
> sending client refusing to transmit the message. Support for
> both protocols is increasing, but is not yet mandatory.
> 
> These two protocols differ from Opportunistic TLS in that they
> require receiving server authentication and there is no
> fallback to sending in the clear if negotiation of an
> encrypted connection fails.
> 
> Note: Both protocols mentioned in this section rely not only
> on the receiving server but also the sending client supporting
> the protocol intended to be used. If the sending client does
> not implement or understand the protocol requested by the
> receiving server, the sending client will use Opportunistic
> TLS or clear-text to transmit the message.
> 
> Protocols exist to allow for authentication of different
> identities associated with an email message - SPF [RFC7208]
> and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies
> on SPF and DKIM to allow for validation of the domain in the
> visible From header, and a fourth, ARC [RFC8617], provides a
> way for each hop to record results of authentication checks
> performed at that hop.
> 
> All of these are outside the scope of this document, as they
> are outside the scope of SMTP. They deal with validating the
> authorized usage of one or more domains in an email message,
> and not with establishing the identity of the receiving server.
> 
> 5.4 SMTP Authentication
> 
> SMTP Authentication, which is often abbreviated as SMTP AUTH,
> is an extension to SMTP. While its name might suggest that it
> would be within scope for this section of the Applicability
> Statement, nothing could be further from the truth.
> 
> SMTP AUTH defines a method for a client to identify itself to
> a Message Submission Agent (MSA) when presenting a message for
> transmission, usually using port 587 rather than the
> traditional port 25. The most common implementation of SMTP
> AUTH is for a person to present a username and password to
> their mailbox provider's outbound SMTP server when
> Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist
> to allow for message confidentiality outside of the operation
> of SMTP. That is to say, using these protocols results in
> encryption of the message prior to its being submitted to the
> SMTP communications channel, and decryption of the message is
> the responsibility of the message recipient. There are numerous
> implementations of these protocols, too many to list here. As
> they operate fully independent of SMTP, they are out of scope
> for this document. =========================== cut here
> =========================

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 28 Jan 2022 17:33:44 +0100

On Fri 28/Jan/2022 00:45:28 +0100 Dave Crocker wrote:
>> performed for the target receiving server and is not done for the 
>> sending client. That is, it serves to validate that the connection 
>> has been made to the intended server, but does not validate who 
>> initiated it.
> 
> by the sending client of the target receiving server. That is, it 
> serves to validate that the connection has been made to the intended 

To be even more clear, I'd add something like "Sending client 
authentication is usually done on the first hop only, see Section 5.4".

>> [...]
>> Two protocols exist [...] Support for both protocols is

Mandatory -> widespread (or prevalent?) at the time of this writing.

jm2c
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 31 Jan 2022 22:33:46 -0500

>authentication is usually done on the first hop only, see Section 5.4".

I'm not sure whether you are referring to authentication OF the sending client
or BY the sending client, but either way, it seems wrong.

Authentication BY the client happens on a hop to a server located
using an MX or maybe A/AAAA record, using DANE or MTA-STS to check
that the server is the one it's looking for. All the other hops are
within the sending or receiving system which presumably has knowledge
if its internal structure so there's nothing to authenticate.

Authentication OF the client doesn't happen at all unless I supose
you're talking about DNS checks on the HELO name, or you're mixing
submission with SMTP.

R's,
John