Open klensin opened 3 weeks ago
-- Consequently, as knowledge of Internet mail increases, so does the -- knowledge that SMTP mail inherently cannot be authenticated, or -- integrity checks provided, at the transport level. Real mail -- security lies only in end-to-end methods involving the message -- bodies, such as those that use digital signatures (see RFC 1847 [26] -- and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [49] or Secure/ -- Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [45]).
++ SMTP can benefit from transport layer security, as desrcribed in ++ "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) ++ or Email Submission and Access" [RFC 8314]. However, this technology ++ by definition only covers a single hop. End-to-end methods involving ++ the message bodies cover every hop. Examples that use digital signatures ++ include RFC 1847 [26], Pretty Good Privacy (PGP) in RFC 4880 [49] ++ or Secure/Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [45].
I think this is a better way to say it.
I noticed the author tried to put the burden of proof on me here, despite many similar comments. I don't think this one is right. RFC 8314 is IETF consensus, so the document must obsolete that or incorporate something like my proposal. I am not attached to the precise wording.
I'll try again:
SMTP can benefit from transport layer security. "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access" [RFC 8314] provides an overview of many approaches. However, this technology by definition only covers a single hop. End-to-end methods involving the message bodies cover every hop. Examples that use digital signatures include RFC 1847 [26], Pretty Good Privacy (PGP) in RFC 4880 [49] or Secure/Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [45].
Trying to keep it at about the same level of detail as Mail Agents and Message Stores.
In his review of rfc5321bis-32, Donald Eastlake said:
"Section 7.1, particularly re 2nd paragraph: I think it would be useful to mention something like the following:
"1. Transport authentication between SMTP systems could improve the authenticity of the Received line added by a server but does not protect those lines against modification, in violation of this document, by subsequent SMTP systems.
"2. Nation State intelligence agencies and others on occasion, have been known, even in the case of extremely high bandwidth traffic mixing many streams, for example between large data centers, as well as lower bandwidth connections, to capture and hold immense quantities of raw traffic for potential later analysis, so there may be good reason to encrypt transmissions between SMTP systems."
For reasons discussed elsewhere, probably does not belong in 5321bis, but should probably be considered for Section 6 of the A/S.