--On Friday, March 28, 2025 11:16 -0700 Eric Rescorla <ekr@xxxxxxxx> wrote: > On Wed, Mar 26, 2025 at 3:09 PM Dave Crocker <dhc@xxxxxxxxxxxx> > wrote: >... >> Having DKIM cover the From: field does not carry any assertion of >> authenticity. > > The d= field alone is in fact a form of authenticity. Otherwise it > wouldn't be useful. I don't dispute that the authenticity properties > are complicated, but I don't think that's an argument for exclusion. Actually, it _is_ part of the argument for exclusion from the 5321bis document. The terms "authenticity" and "authentication" have, in email contexts, been used since at least the 1980s to refer to a message actually having been sent by an individual who is the purported sender, including the message content being an accurate representation of what was sent. That definition, or something close to it, is the one that typical email users understand (and have understood for decades). I believe that many (or most) of those users would even think of that as the common sense definition. That does not mean that there cannot be other forms of authenticity --especially in discussions among security specialists-- only that, in an email document, talking about (other) forms of authenticity requires additional (and, as you point out, complicated) explanation of just what is being authenticated. When the WG's charter was being defined (and agreed by the IESG and community), that was a key reason why the instructions to the WG were to work on what became 5322bis and 5321bis, doing only a "limited review", making only minimal changes and "avoiding broader changes to terminology...". As part of the agreements about the charter, development of the Applicability Statement was specified "to capture relationships to other documented and widely deployed work...". Even if there were no other reasons, one of the very strong reasons for leaving DKIM, and the explanations it requires, out of 5321bis is that those explanations simply are not part of those minimal changes to SMTP even if one ignores the question of whether various security mechanisms and extensions should be considered necessary parts of SMTP at all. What should be said about DKIM (or other mechanisms) in the Applicability Statement is, as Orie has reminded us, far out of scope for this Last Call discussion. >> > the mail server operator will often be able to control who gets >> > a credential for a given user at that domain. >> >> Sure. All sorts of good practices. Entirely outside the DKIM >> spec. > Actually, this sentence was talking about the fact that the owner > of the domain is generally free to reassign accounts to other people > and thus application-layer signing systems such as S/MIME > may not provide protection from the owner of the domain > impersonating a given user. And that may be a powerful argument for avoiding using the DNS for storing certificates or other credentials, at least unless the methods by which those credentials are signed (or otherwise authenticated (sic)) are under the control of the user and independent of the domain (or mail server) owner/operator. It might be worth noting that, when S/MIME and PGP (Open or otherwise) were defined, the assumption was that signature and repository mechanisms for credentials were independent and highly trusted in ways that DNS owners/operators will never be in the general case. Again, to the extent to which those issues need discussion for the email context, 5321bis is the wrong place to have that discussion. >> DKIM was designed to permit any handler of the message to do >> signing, including the MUA, or other components that are not MTAs. >> >> Ultimately language such as you suggest promotes a >> misunderstanding of what DKIM does and does not do. This >> misunderstanding is pervasive, and very much counterproductive. > > This seems like an argument for accurately stating those properties > in the relevant paragraph that talks about other signing mechanisms, > rather than just omitting it entirely. Exactly. See above for the argument that the properties do not belong in 5321bis and that DKIM should not be included there (or even in the A/S) without a statement and explanation of those properties. If, instead, you are arguing that mention of S/MIME and/or OpenPGP should be removed from 5321bis, two observations: (1) Because those specs were mentioned in RFC 2821 (in 2001), they are not new to 5321bis at all, much less changes since the initial IETF Last Call. Consequently, a discussion of what, if anything, should be done with them is outside the scope specified for this Last Call. (2) This is also out of scope, but it seems to me that a discussion of risks of using them if the credentials/certificates cannot be reliably authenticated to a user/sender could be put into the Applicability Statement and/or that some clear document from the Security Area describing the risks and vulnerabilities of our collection of signing and/or encryption mechanisms (rather than avoiding those discussions or burying them deep in protocol specifications) has become overdue. best, john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
