On Mon, Oct 28, 2024 at 12:55 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 29-Oct-24 07:19, Rob Sayre wrote:
>
> 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.
Maybe we could say "the security situation is unclear as written" and let John handle that with an extra sentence. What's not going to happen is a "fix". We're in the descriptive phase.
thanks,
Rob
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
