Subject: [Emailcore] Ticket #54 - Proposed Text for Applicability Statement

From: Todd Herr <[email-masked]>
Date: Wed, 19 Jan 2022 08:36:45 -0500

Greetings.

Alexey mentioned in a separate message that I would be posting proposed
text for the subject ticket. This is that posting.

The ticket is ticket number 54 -
https://trac.ietf.org/trac/emailcore/ticket/54

The ticket description reads:

Should this document discuss hop-by-hop authentication or, for that
matter, encryption?

and there is a suggestion that such discussion be done in the Applicability
Statement.

Here is an initial proposal for text for the Applicability Statement to
discuss these topics.

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

5. Hop-by-hop Authentication and Its Implications

Two 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, but users and
implementers of SMTP should be aware of them and most critically of the
fact that both SPF and DKIM verification checks can produce different
results when a message transits multiple hops vice when it goes directly
from the sender to the destination, specifically “FAIL” results. These
unanticipated failures can and do affect DMARC verification results on some
messages, and so domain owners should be aware of this when setting DMARC
policy for their domains. As for message receivers, the ARC protocol is one
attempt to provide evidence of the results of previous authentication
checks, and it’s up to the receiver to decide if they trust the results and
how those results might impact message handling at their site.

6. Message Encryption and Its Implications

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,
solutions have been developed to encrypt the message in transit, either
just between servers or through the entire path from sender to message
store. This section will touch on these methods and the implications of
their use.

6.1 Opportunistic Encryption

The most common implementation of message encryption is what’s known 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.

Most modern implementations of SMTP support this method, and so the vast
majority of email traffic is encrypted during its time transiting from the
client to the server.

6.2 Required Encryption

Two protocols exist that move server-to-server encryption beyond “nice to
have” 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 is
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.

6.3 Personal Encryption

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 are
too numerous to list here, and debugging any issues that may arise in
message transmission is likely to be beyond the scope of any MTA
administrator’s work, but they’re nonetheless mentioned here for the sake
of completeness.

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

Please discuss...

-- 

*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: 19 Jan 2022 10:46:02 -0500

It appears that Todd Herr  <[email-masked]> said:
>-=-=-=-=-=-

DKIM and DMARC are end to end, SPF is hop by hop, but when I think of hop-by-hop
authentication and encryption, I think of mta-sts and STARTTLS.

R's,
John