--On Tuesday, October 29, 2024 08:55 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: >... >> 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. A change I'm happy to make if the WG is ok with it, but note that this is another one of those sentences that has been with us since at least RFC 2821 in 2001. I don't have time to run it down but I suspect it may come from even earlier text. As I have suggested before, I (and I assume the WG) would really appreciate it if people would read Sections 1.1 and 1.2 and understand the present document in the context of the latter. Should we have completely rewriten the thing around 2000 instead of patching multiple documents together? Perhaps so. But, unless someone has the resources to hire a very good technical editor with an understanding of IETF protocols to do that _and_ knows how to put together a WG with the energy to ensure that any inadvertent errors are caught and corrected, that certainly is not going to happen now. So, the question is whether it is worth changing this one sentence is worth it given dozens of other rough edges in the document. And, for this case, if "SMTP" were not specifically a "Mail Transport Protocol", the improved sentence would not look as redundant. > So I am a bit surprised that the next sentence > doesn't require STARTTLS and cite RFC 3207 and RFC 7817. It seems I'm happy to have you ask Alexey to create a ticket and have the WG discuss this, but my quick answer answer is that such citations would just about require an analysis of problems those specifications would and would not solve. That analysis would probably be controversial and drag things out further. > 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. Only if the scenario Paul Wouter's describes as: > In practise, the pipeline is a few hops trusted by the sender, > followed by a direct delivery to the mx target with no > intermediate/backup MX, followed by a few anti-spam hops trusted by > the receiver. So the chance of email modification is low. were universally true. Unfortunately, once one ventures significantly out of the words of what many in the email environment might describe as gorilla <-> gorilla or smaller provider <-> gorilla communications, it isn't. As soon as either: * a relay enters the system that can potentially be compromised or * the (human) sender or receiver has little or no reason to trust their email provider (especially a provider -- possibly including governmental entities-- that is under the control of a party interested in the message content or one whose business model includes harvesting and using or selling information) the protection offered by TLS and similar tools becomes dubious at best. > Just a couple of sentences could capture these threats and STARTTLS > as the mitigation. Having tried in other contexts, I don't think so. And STARTTLS provides no mitigation at all if the message can be captured while it sits on an intermediate system. > 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. Yep. I just noticed that another 15 messages came in while I was working on this one. Maybe tomorrow. And maybe then I can finish up the half-complete response to Donald's note. As a preview in case I can't get back to it or the additional messages distract me, two observations: (1) I would welcome a document that carefully analyzed the threat models for SMTP/Message Format based email (including both confidentiality and authentication), presented remedies, and analyzed their strengths and weaknesses (including attacks against the remedies themselves). Ideally, I'd like to see an end to end analysis that would also include submission servers and some issues draft-ietf-emailcore-rfc5322bis probably should have covered if the same criteria for an adequate Security Considerations section were applied there. However, I think it would be a major effort and not, e.g., "a couple of sentences" that could be dropped into SMTP/rfc5321bis or even into draft-ietf-emailcore-as. Whether some halfway or half-baked approximation (with "half" possibly being too optimistic) would be worth the trouble and the risk of confusion or misleading users that it might cause leads to the other observation. (2) If we are in a situation where those whose concerns about the presentation and coverage of security issues believe that this document should not move forward unless their concerns are addressed as they would prefer, this is likely to turn into a question for the IESG (and perhaps the larger IETF community) as to whether to agree with that position and, if so, whether we are better off with this document or dropping it and staying with RFC 5321. While I'd be happy to be wrong, experience over the last year of so causes me to doubt that the WG has the energy to complete the needed analysis in a way that would be satisfactory to all concerned. I am, again, only guessing about how the WG feels about the above, but these issues have been discussed enough there that it is not a completely wild guess. best, john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
