On 29-Oct-24 07:19, Rob Sayre wrote:
On Mon, Oct 28, 2024 at 11:07 AM John R. Levine <johnl@xxxxxxxx <mailto:johnl@xxxxxxxx>> wrote: On Mon, 28 Oct 2024, Eric Rescorla wrote: > As I said, I'd prefer the security considerations in this document to be > complete but I could live with them being in a separate document provided > there was a normative reference to said document. If you don't think that's > a valid alternative, then I think the appropriate resolution is to properly > update the security considerations in this document. Keeping in mind that this protocol is 40 years old, and most of the security issues are addressed higher up the stack than the SMTP level, who do you see as the targets or beneficiaries of that update? The only significant thing I can think of that happens at the SMTP level is TLS security, so I suppose it could point to STARTTLS, which is described in RFC 3207, and to encourage people to use TLS, mention MTA-STS which is in RFCs 8460 and 8461, or TLSA, which is in RFCs 6698 and 7671. Those are all optional extensions, not part of the protocol described here. I could certainly see a separate document that gives an overview of the state of mail security, but stuffing it into this revision of 5321 seems like process for process' sake. This one is a special case. If the IETF is good at anything, it is accomodating special cases. I think the document could use a sentence here saying what it doesn't cover. SMTP is incredibly insecure, but that's the state of play.
I've been trying to stay out of this one, but here goes. The Security Considerations start by saying "SMTP mail is inherently insecure" which is undoubtedly true, although "Transmission of mail via SMTP is inherently insecure" might be more precise. So I am a bit surprised that the next sentence doesn't require STARTTLS and cite RFC 3207 and RFC 7817. It seems to me that this would be a practical response to Donald's comments about transport authentication and surveillance, and I don't see why it should be kicked to the future Applicability Statement. In particular, it deals with both threats against SMTP (a *transfer* protocol) - alteration to the content, and capture of the content. Just a couple of sentences could capture these threats and STARTTLS as the mitigation. I agree with John Klensin that DMARC, DKIM and the like are out of scope for SMTP as such. They aren't part of simple mail *transfer* so they don't belong here. The rest of the Security Considerations are really about operational security and, presumably, are based on experience. Regards Brian -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
