--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. > .. . .. Francesco, 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. 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. > 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. thanks, john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
