On Sat, Mar 29, 2025 at 2:18 PM John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --On Saturday, March 29, 2025 12:32 +0100 Francesco Gennai > <francesco.gennai@xxxxxxxxx> wrote: > > > On Sat, Mar 29, 2025 at 3:27 AM Viktor Dukhovni > > <ietf-dane@xxxxxxxxxxxx> wrote: > > > >> On Fri, Mar 28, 2025 at 06:21:01PM -0700, Rob Sayre wrote: > >> > >> > I propose deleting this section entirely: > >> > > >> > > >> https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321 > >> bis-42#section-7.1 > >> > > >> > The AS covers it well, and I do understand the desire not to put > >> > some transient specs in this document. > >> > > >> > Look at the first part: "The authenticity of SMTP mail is > >> > inherently insecure". > >> > >> If it is possible to reach consensus on a more modest/concise > >> version of 7.1, I would not be opposed, provided: > >> > >> - The benefit justifies an effort to reach such consensus. > >> - Such a simplification is in scope for the document update. > >> > >> Minimal replacement text to refine could be: > >> > >> Authentication of message origin and content lies outside the > >> scope of the core SMTP protocol specified in this document. > >> In general one cannot assume that the envelope sender address, > >> "From:", "Sender:" or other headers are not forged, that the > >> message is not a replay, or that it has not been materially > >> modified in transit. > >> > >> Various extensions of the SMTP protocol and/or message > >> structure offer partial mitigations of the above risks, but no > >> holistic scalable solution has yet been developed. > >> > >> But it is not clear that expending the effort to reach consensus > >> is in scope or justified. > >> > > > > Trying to reach consensus with a minimal change, could DKIM be cited > > in this paragraph? (always from section 7.1): > > > > Various protocol extensions and configuration options that > > provide authentication at the transport level (e.g., from an > > SMTP client to an SMTP server) improve somewhat on the > > traditional situation described above. However, in general, > > they only authenticate one server to another rather than a chain > > of relays and servers, much less authenticating users or user > > machines. Consequently, unless they are accompanied by careful > > handoffs of responsibility in a carefully designed trust > > environment, they remain inherently weaker than end-to-end > > mechanisms that use digitally signed messages rather than > > depending on the integrity of the transport system. > > > > for example: > > > > Various protocol extensions and configuration options that > > provide authentication at the transport level (e.g., DKIM > > [RFC6376]) improve somewhat on the traditional situation > > described above. However, in general, they only authenticate > > one server to another rather than a chain of relays and servers, > > much less authenticating users or user machines. > > .. . .. > John, thank you for your detailed and clear answer. I would clarify that I don't agree (like many others, I think) to insert DKIM in the first part of paragraph 7.1. > > > Let me see if I can explain what the problem --both with your very > thoughtful suggestion and some others I think are, at best, less > complete -- looks like from my point of view. The sentence without > the specific reference is clearly hand waving, but that is probably > ok precisely because it does not point to any particular spec. Per > my earlier exchange with ekr, if we do cite DKIM, we have some > obligation to explain what "authenticate" means because what DKIM > does is not what most of the email community (implementers and users) > have traditionally meant by that term. I suspect that explaining what "authenticate" means should clarify why DKIM should not be cited in 7.1. I would add: PGP and S/MIME have totally different semantics of DKIM. And the 7.1 says: Very high confidence in the authenticity of a message and its originator lies only in end-to-end methods involving the message bodies DKIM is not an end-to-end method. PGP and S/MIME are end-to-end and can offer such authenticity (and much more) also by establishing policies, trust and so on.... They have been developed for such scope. DKIM no. In the first message of Eric Rescorla (at the end): Signatures applied by the originating MTA as in DKIM [XX] also provide strong authenticity, subject to the correct behavior of that MTA. *if* that MTA has the correct behavior.... and the recipient, often, knows nothing about the MTA provider of the sender. That doesn't means that DKIM cannot be used to certify/authenticate something out of the scope of DKIM, but it is just a non conformant application of the specification (DKIM). > And, as soon as we start > explaining that, we are not adding a few words but starting down the > slippery slope of explaining DKIM and its limitations. We could do > some of that by pointing to specific sections of the current DKIM > document and citing draft-gondwana-dkim2-motivation, but that runs > into the difficulty of a document that we expect to be very stable > over a long period of time (rfc5321bis) citing documents that are in > flux. > > In principle, we could cite DKIM in more or less the fashion you > suggest and point people to the A/S for a more complete explanation. > However, there seems to be little agreement so far about what such an > explanation should be. If the reference to the A/S were still > informative, I/we could probably devise some text to the effect of > "that document is expected to include...", but long-standing > principles about stability of references materials (and, arguably, > common sense) prevent doing that with a normative reference. I agree. > > > Off topic respect to this discussion: > > > > I noticed that the original paragraph states: > > > > Various protocol extensions and configuration options that provide > > authentication at the transport level > > ***> (e.g., from an SMTP client to an SMTP server) > > improve somewhat on the traditional situation > > described above. > > > > However, in general, > > ***> they only authenticate one server to another > > rather than a chain of relays and servers > > > > client-server in the example then > > "they only authenticate one server to another > > that does not sound perfectly aligned. > > Good catch. The source of the problem is that we've got some of > those extensions that help assure a client that it is talking to the > right server and others (or variations on the same ones) that try to > assure servers about the legitimacy or authenticity or the client or > the incoming message. Speaking as author/editor, if we can agree > that this is an editorial problem, rather than a substantive one for > which specific consensus is needed, I'll try to figure out how to > adjust the wording without making it much more complicated. If we > cannot reach that agreement, it is not clear to me that an > improvement is worth further holding up the document (and, at least > indirectly, progress on the A/S) for another round of Last Calls and > impassioned discussions. I agree that this is an editorial problem. Whoever reads the specification definitely has a good background to understand the little editorial problem. Thanks, Francesco > > thanks, > john > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
