I propose deleting this section entirely:
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".
That is not a precise phrase.
thanks,
Rob
On Fri, Mar 28, 2025 at 6:01 PM John C Klensin <john-ietf@xxxxxxx> wrote:
--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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
