Subject: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S

From: Todd Herr <[email-masked]>
Date: Mon, 24 Jan 2022 18:18:26 -0500

Greetings.

Thanks to all who attended the interim on January 21.

I've listened to the recording a couple of times and reviewed the notes (
https://notes.ietf.org/notes-emailcore-interim-jan-2022) in an effort to
propose better text for the subject topic. Before I really start writing,
though, I want to throw the following outline to the group to see if it's
directionally correct.

   - Define encryption (transmitting messages in ciphertext, rather than in
   the clear, to provide privacy of communication) and authentication
   (establishing the identity of the hosts involved in the transaction), both
   done using TLS.
   - Discuss opportunistic TLS (sometimes called opportunistic encryption)
   and mention that it's encryption without authentication.
   - Discuss MTA-STS and DANE for SMTP, which are both encryption with
   authentication.
   - Mention SPF, DKIM, DMARC, and ARC, which are authentication protocols,
   but not the kind of authentication we're talking about here.
   - Mention private use message encryption (e.g., PGP) but only for the
   purposes of mentioning that it's out of scope for the A/S

Appreciate your collective feedback, to include suggested text for the
definitions of encryption and authentication.

-- 

*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: "John Levine" <[email-masked]>
Date: 24 Jan 2022 21:59:54 -0500

>   purposes of mentioning that it's out of scope for the A/S

Seems reasonable.

>definitions of encryption and authentication.

You would think we would have standard text for those by now.

Since we use TLS, the encryption and authentication for mail servers is the same
as for web servers, so that might be a good place to look.

R's,
John

---

From: Todd Herr <[email-masked]>
Date: Tue, 25 Jan 2022 16:21:32 -0500

Here is my post-interim suggestion for text to use in the A/S to cover the
topics of Confidentiality and Authentication

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

5. Confidentiality and Authentication with SMTP

The default method for transmitting text using the SMTP protocol is to do
so “in the clear”. Years of operational experience have shown that such
transmission exposes the message to easy compromise. To mitigate this risk,
SMTP has evolved over the years to allow for easy integration and support
of Transport Layer Security (TLS - RFC8446) to provide both confidentiality
and authentication in the transmission of messages. This section will
discuss those topics and their most common uses.

It is important that the reader understands 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 the
   endpoints (e.g., the hosts) of the SMTP transaction
   -

   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.

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.

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, an SMTP server announces in its greeting
that it is capable of supporting TLS encryption through the presence of the
“STARTTLS” keyword. The SMTP client then attempts to negotiate an encrypted
connection, and if successful, transmits the message in encrypted form;
there is no guarantee that the message will be stored in encrypted fashion
at its destination, and in fact, storage in plain text should be expected.
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 endpoints of the transmission, 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 the SMTP protocol 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 Authentication

Two protocols exist that move message confidentiality from optional to
required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ
in their implementation details, SMTP 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
SMTP client refusing to transmit the message. Support for both protocols is
widening, but is not yet mandatory.

These two protocols differ from Opportunistic TLS not only because they
require message confidentiality, but also because they require
authentication.

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 the SMTP protocol. They deal with authentication of the
message, not the endpoints.

5.4 Message-Level Confidentiality

The more sophisticated among the end users of SMTP may take advantage of
various third party solutions that are designed to encrypt their message
immediately upon leaving the MUA, and to do so in such a way that only the
individual message recipient(s) can decrypt the message. The solutions
(e.g., PGP) are too numerous to list here, and as they operate at the
message level rather than the SMTP protocol level, they are out of scope
for this document.
=================================================== cut here
===============================================

Have at it...

--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jan 2022 15:27:49 -0800

On 1/25/2022 1:21 PM, Todd Herr wrote:
> Here is my post-interim suggestion for text to use in the A/S to cover 
> the topics of Confidentiality and Authentication
> 
> The default method for transmitting text using the SMTP protocol is to 
> do so “in the clear”. 

I suggest not casting it as the default.  It's not that the statement is 
wrong, but I think it sets the stage in a way that casts the protection 
mechanisms as exception.

So, perhaps:

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. 

... comprise, including wiretapping and spoofing.

 >  To mitigate
> this risk, 

these risks

SMTP has evolved over the years to allow for easy integration
> and support of Transport Layer Security (TLS - RFC8446) to provide both 
> confidentiality and authentication in the transmission of messages. 

Hmmmm.  I think SMTP has not evolved at all.  What has evolved is the 
operational choice to run it over TLS.  Have I missed changes to SMTP, 
itself?

If my understanding is correct, then perhaps:

Operation of SMTP has evolved over the years, so that it is used with 
the benefit of Transport Layer...

This
> section will discuss those topics and their most common uses.

will discuss -> discusses

> It is important that the reader understands what is meant by the terms 

understands -> understand

>   *
>   *
>     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.
> 
> “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.

nicely written!

A point of clarification worth adding, especially since it is usually 
missed but is extremely important:

      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.

It's probably worth hammering this point a bit, such as changing any 
reference to authentication to be "receiving server authentication" or 
somesuch.

> 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, an SMTP server announces 
> in its greeting that it is capable of supporting TLS encryption through 
> the presence of the “STARTTLS” keyword. The SMTP client then attempts to 
> negotiate an encrypted connection, and if successful, transmits the 
> message in encrypted form; there is no guarantee that the message will 
> be stored in encrypted fashion at its destination, and in fact, storage 
> in plain text should be expected. If negotiation fails, the client falls 
> back to sending the message in clear text.

Since I think this needs very strong emphasis, perhaps breaking out and 
indenting the 'no guarantee' text, such :

    Note: TLS provide protection while mail is in transit, but it does
          NOT mean that there is any mail encryption while the message is
          stored in a sever.  In fact, storage in plan text should be
          expected!

> effort is made to authenticate the endpoints of the transmission, 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 the SMTP protocol 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.
> 
> required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they 
> differ in their implementation details, SMTP 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 SMTP client refusing to transmit the message. Support 
> for both protocols is widening, but is not yet mandatory.

widening -> increasing

> require message confidentiality, but also because they require 

since TLS provides confidentiality, I think the requirement for 
authentication is the only difference.

> [RFC8617], provides a way for each hop to record results of 
> authentication checks performed at that hop.
> 

the SMTP protocol -> SMTP

(the P in SMTP stands for "protocol"...)

> immediately upon leaving the MUA, and to do so in such a way that only 
> the individual message recipient(s) can decrypt the message. The 
> solutions (e.g., PGP) are too numerous to list here, and as they operate 
> at the message level rather than the SMTP protocol level, they are out 
> of scope for this document.

Since S/MIME and OpenPGP have RFCs, I suggest citing them, though noting 
that there are many proprietary solutions in use is reasonable, of course.

> =================================================== cut here 
yum...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 25 Jan 2022 15:39:31 -0800

> confidentiality.  Its traffic is therefore "in the clear".

"The original SMTP specification was created before embedded mechanisms 
for authentication or confidentiality became the norm. As such, it's 
traffic can be transmitted "in the clear", with the accompanying risk of 
exposing sensitive information, including passwords."

Does that sound better? It's a clear indication that it's time to do 
things differently than the original specifications.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Jan 2022 15:45:41 -0800

> things differently than the original specifications.

First, nothing being done now changes SMTP.  It changes packaging around 
SMTP.  This is not a minor point.  This is, therefore, a matter of 
changes to the 'service' rather than to the 'protocol', and certainly 
not to the specification of the protocol.

Second, the historical perspective is interesting briefly, perhaps, but 
is not interesting or useful for the long term.  That's why the phrasing 
I chose focuses on simple technical differences and does not have to 
tone of judgement about deficiencies in the past or superiority of the 
present.

d/

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 25 Jan 2022 15:58:28 -0800

> require message confidentiality, but also because they require 

Sorry, won't make any suggestions on this section, but do want to point 
out this is unclear, as it makes a statement about server-server 
communication, and then speaks about the SMTP client which is confusing.

Are we missing something here as well?

Another example of 'Required Confidentiality' is when a server does not 
allow authentication without SSL or TLS encryption for sending.  Is 
there something you can reference, that speaks directly to supporting 
plain text authentication is no longer recommended?

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 26 Jan 2022 13:55:33 +0000

Potential nuance with MTA-STS, there is a “testing” mode which does allow for senders to ignore TLS validation errors and continue with message transmission. I’m not sure if that should be noted here, or left to the reader to glean from RFC8461.

I’m not sure how to frame this in the paragraph below, but when a server deploys MTA-STS/DANE, the mechanisms are still dependent on the client implementing one/both of these to ensure the proper protections are in place.  If the client does not understand MTA-STS/DANE, they’ll use Opportunistic TLS (or clear-text if that fails) when transmitting the message.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: Emailcore <[email-masked]> On Behalf Of Todd Herr
Sent: Tuesday, January 25, 2022 4:22 PM
To: [email-masked]
Subject: Re: [Emailcore] Ticket #54 - Take Two - Authentication and Encryption for A/S

Here is my post-interim suggestion for text to use in the A/S to cover the topics of Confidentiality and Authentication

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

The default method for transmitting text using the SMTP protocol is to do so “in the clear”. Years of operational experience have shown that such transmission exposes the message to easy compromise. To mitigate this risk, SMTP has evolved over the years to allow for easy integration and support of Transport Layer Security (TLS - RFC8446) to provide both confidentiality and authentication in the transmission of messages. This section will discuss those topics and their most common uses.

It is important that the reader understands 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 the endpoints (e.g., the hosts) of the SMTP transaction
  *   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.

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.

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, an SMTP server announces in its greeting that it is capable of supporting TLS encryption through the presence of the “STARTTLS” keyword. The SMTP client then attempts to negotiate an encrypted connection, and if successful, transmits the message in encrypted form; there is no guarantee that the message will be stored in encrypted fashion at its destination, and in fact, storage in plain text should be expected. 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 endpoints of the transmission, 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 the SMTP protocol 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.

Two protocols exist that move message confidentiality from optional to required - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their implementation details, SMTP 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 SMTP client refusing to transmit the message. Support for both protocols is widening, but is not yet mandatory.

These two protocols differ from Opportunistic TLS not only because they require message confidentiality, but also because they require 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 the SMTP protocol. They deal with authentication of the message, not the endpoints.

The more sophisticated among the end users of SMTP may take advantage of various third party solutions that are designed to encrypt their message immediately upon leaving the MUA, and to do so in such a way that only the individual message recipient(s) can decrypt the message. The solutions (e.g., PGP) are too numerous to list here, and as they operate at the message level rather than the SMTP protocol level, they are out of scope for this document.
=================================================== cut here ===============================================

Have at it...

--
Todd Herr | Technical Director, Standards and Ecosystem
e: [email-masked]<mailto:[email-masked]>
m: 703.220.4153
[https://hosted-packages.s3-us-west-1.amazonaws.com/Valimail+Logo.png]

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: John C Klensin <[email-masked]>
Date: Wed, 26 Jan 2022 16:49:18 -0500

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

> https://notes.ietf.org/notes-emailcore-interim-jan-2022) in an
> effort to propose better text for the subject topic. Before I
> really start writing, though, I want to throw the following
> outline to the group to see if it's directionally correct.
> 
>    - Define encryption (transmitting messages in ciphertext,
> rather than in    the clear, to provide privacy of
> communication) and authentication    (establishing the
> identity of the hosts involved in the transaction), both
> done using TLS.
>    - Discuss opportunistic TLS (sometimes called opportunistic
> encryption)    and mention that it's encryption without
> authentication.    - Discuss MTA-STS and DANE for SMTP, which
> are both encryption with    authentication.
>    - Mention SPF, DKIM, DMARC, and ARC, which are
> authentication protocols,    but not the kind of
> authentication we're talking about here.    - Mention private
> use message encryption (e.g., PGP) but only for the
> Appreciate your collective feedback, to include suggested text
> for the definitions of encryption and authentication.

Todd,

(personal opinion only)
I've read your later note, but think I should respond to this
one.

First, I agree, plus or minus wordsmithing, with Dave Crocker's
suggestions.

However, if we are going down this path, I think it is important
to be very precise.    Two examples:

* At least as far as I know, none of the TLS-based techniques
provide confidentiality from submission to delivery or even from
the first entry into the SMTP system until the message reaches
the delivery server (as RFC 5321 defines that term), at least
unless it can be guaranteed that there will be a direct
connection between those two systems (i.e., no MX or other
relays that need to have at least the envelope in clear to route
the message or even post-delivery processing before the
receiving user gets the message into an MUA or equivalent).
The distinction is, or at least used to be, important because,
with the exception of attacks by governments, there were far
more successful attacks on servers than on network
infrastructure.  On the other hand, if the concerns about link
encryption really are about protection from government snooping,
it may be time we get much more clear about that.

* It is also important to distinguish between authentication of
the person who originated the message, authentication of the
originating system (submission server or first-hop MTA), and
authorization of the sending address to initiate messages from
that sending system and/or domain.   

While I hope everyone reading this is familiar with the above
(whether they agree with me or not), the likely audience for the
A/S may not be and we should not mislead them by, e.g., using
phrases like "Confidentiality between Endpoints" without
defining that very carefully and/or describing its limitations.

In addition, I have noticed that
draft-ietf-lamps-e2e-mail-guidance appears to be progressing in
the LAMPS WG.  Someone may want to start coordinating soon
because it would be really unfortunate to end up with guidance
about email from LAMPS that was inconsistent with guidance from
EMAILCORE... and perhaps even more unfortunate to discover the
conflicts during IETF Last Call on one document or the other.

best,
   john