On Mon, Oct 28, 2024 at 12:56 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > 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. There's already a reference to PGP and S/MIME in 7.1, which cross to higher levels to solve the problems of lower ones like transport. We could add in a reference to DMARC, DKIM, etc, something like "Solutions such as DMARC (ref), DKIM (ref) authenticate sending servers based on domain in FROM address, but have limitations. In particular they complicate intermediaries like mailing list software". I agree we should also add STARTTLS as a mitgation for hop-by-hop monitoring. I agree that this is somewhat out of scope for pure transport, but I think that readers should know these technologies solve some of the issues. In fact I'm really confused: paragraph 3 of 7.1 seems to be about DKIM and the like without explicitly naming it. A reference here would make the text more understandable, without changing its meaning. I'm having trouble squaring this with declarations that this is out of scope. I don't think people are asking for a very comprehensive treatment, but I do think a discussion that says "here are some imperfect solutions to the problems left" would be useful, even without a forward reference to the A/S. I understand not wanting to start a cluster via a forward reference, but the price of that is having to pull some small things forward. Sincerely, Watson > > 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 -- Astra mortemque praestare gradatim -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
