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

[John C Klensin <[e-mail]>]

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=[e-mail]> 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.
> 
> =========================== 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
> =========================