G.7.17 Hop-by-hop Authentication and/or Encryption

[ietf-svn-bot]

owner:todd.herr@valimail.com type_defect | by alexey.melnikov@isode.com

---

John Klensin wrote:

Should this document discuss hop-by-hop authentication or, for that
matter, encryption? (See CREF in Section 2.)

---

Issue migrated from trac:54 at 2022-01-31 12:38:23 +0000

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Suggestion that nothing should be said in rfc5321bis, but something should be said in the A/S draft.

[ietf-svn-bot]

@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com

[ietf-svn-bot]

@alexey.melnikov@isode.com changed component from smtp to email-applicability-statement

[ietf-svn-bot]

@alexey.melnikov@isode.com changed owner from alexey.melnikov@isode.com to todd.herr@valimail.com

[ietf-svn-bot]

@todd.herr@valimail.com commented

---

Text proposed on-list, 27 January 2022 (https://mailarchive.ietf.org/arch/msg/emailcore/JhhcHWHnfzQ6WYs_4smL-V-p1zo/)

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.

[toddherr]

Most recent proposed text, based on on-list discussion through May 10, 2022:

A/S Proposed Text - Confidentiality and Authentication

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 validating an asserted identity of one or more of the endpoints of a communication channel. TLS usage typically only attempts 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 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.

Also worth noting: 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 the MTAs relaying the message or at its destination. In fact, storage in plain text should be expected!

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.

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.

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. It defines a method for a client to identify itself to a server when presenting a message for transmission. The server can be either a Message Submission Agent (MSA) or an MTA. Message submission usually is done using port 587, as per RFC 6409, 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 and integrity 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.

[aamelnikov]

Suggestion to delete "too many to list here" in the next to the last sentence of 5.5. It is not clear why we want to single out S/MIME & OpenPGP. Besides we declare them out of scope anyway.

[aamelnikov]

Closing this, with some minor changes pending.