[Emailcore] Re: draft-ietf-emailcore-as-27

[Jeffrey Walton <[e-mail]>]

On Sat, Jan 24, 2026 at 5:51 PM John C Klensin <[e-mail]> wrote:

> Hi.
> Just in case anyone has been waiting for this note...
>
> draft-ietf-emailcore-as-27 was posted at about 23:48 UTC yesterday
> (15:48 US PST - Secretariat time on January 23).  It contains a
> comprehensive rewrite of Section 6.5 as first proposed by Barry and
> edited according to on-list comments.  It also contains several small
> corrections and adjustments, most if not all of which were also
> proposed and/or discussed on-list.  Some of those reflect a "don't
> try to solve that problem here" approach, e.g., rather than
> substituting "PD" for "PII" as proposed, the document now reflects
> both terms.  It avoids trying to resolve some editorial concerns that
> seem best left to the RFC Editor process.
>
> It does not contain forecasts of the future or other discussions
> that, while interesting, appear out of scope for the document and the
> WG.  As part of that, it continues to try to avoid straying into
> specification of behavior of MUAs.
>
> Please read and comment as appropriate.  Preferably that should be
> soon, rather than waiting for some future deadline, and should stay
> on-topic and in-scope.   The Chairs will presumably guide that
> discussion but, personally, I have developed a strong preference
> similar to one John Levine has expressed several times: let's wrap
> this up and move on rather than continuing to quibble over small
> details that are unlikely to cause any email systems to change
> behavior in practice.  A target that leads to the same conclusion is
> that we are only seven weeks out from the state of IETF 125 and it
> would be really nice, IMO, to have all of this (including
> draft-ietf-emailcore-iana-cleanup on which there has been a shortage
> of on-list comments), wrapped up that we don't need to meet then,
> allowing various of us to concentrate on other IETF commitments.
>
> This note does not address the relationship between changes (or their
> absence) and specific Last Call comments, especially from IESG
> members.  That analysis will follow separately.
>
>    john


Hi John,

The infamous Section 6.  Confidentiality and integrity is being discussed
with respect to SHOULD and MUST.  Here is my contribution...

Section 6.1.1 The TLS Protocol, says:

   The TLS Protocol [RFC8446] [RFC9325] provides confidentiality while
   the message is in transit from an SMTP client to the next SMTP
   server...

Maybe.  It depends on the cipher suite that was negotiated.  IANA provides
eNULL and aNULL cipher suites:[0]

  * TLS_NULL_WITH_NULL_NULL (0x00,0x00)
  * TLS_RSA_WITH_NULL_MD5 (0x00,0x01)
  * TLS_RSA_WITH_NULL_SHA (0x00,0x02)

I checked RFC3207, RFC4954, RFC7672, RFC8446, RFC8461, RFC8689, but I did
not see a treatment of the eNULL and aNULL cipher suites.  However,
RFC9325 Recommendations for Secure Use of Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS) does say, "Implementations
MUST NOT negotiate the cipher suites with NULL encryption."

Do eNULL and aNULL cipher suites meet the confidentiality and integrity
goals or requirements for email messages in this A/S?  (Devil's advocate:
They are using TLS, after all).  Is this something that should be addressed
in the A/S, or maybe even restated from RFC9325 in this A/S?  Or is RFC9325
alone as a separate document sufficient?

Jeff

[0]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4