Perhaps amazingly, I agree with Dave here.
The point of DKIM is to tie a message to a domain name, which meed not
appear anywhere else in the message, so that recipient systems can look at
their mail streams and come to an opinion about the mail signed by that
domain. That opinion is often useful to decide whether to treat a message
as spam, or a phish, but the DKIM signature says nothing at all about
whether the message is "authentic" since bad guys are just as good at
signing as good guys, perhaps better. DKIM doesn't belong in this part of
the A/S and I don't think it belongs in the A/S at all.
R's,
John
On Wed, 26 Mar 2025, Dave Crocker wrote:
On 3/26/2025 9:42 AM, Eric Rescorla wrote:
I believe the following paragraph should have a reference to DKIM,
which also provides a signature over the message.
A continuing question, through these discussions is why? What is the goal for
this topic, in this document, for these readers?
What benefits will accrue? What damage will be done by not having these
texts?
Very high confidence in the authenticity of a message and its
originator lies only in end-to-end methods involving the message
bodies, such as those that use digital signatures on the original
message (see RFC 1847 [27] and, e.g., Pretty Good Privacy (PGP) in
RFC 9580 [51] or Secure/Multipurpose Internet Mail Extensions (S/
MIME) in RFC 8551 [47]).
I recognize that the security properties of DKIM are slightly harder to
state, in part because it does not provide end-to-end signatures, but
it does in fact provide some level of authenticity for the message,
Not really. Or rather, simply NO.
Except for the d= domain name. Authenticity and authorization for that.
Neither for anything else.
Some sites use policies for signing that are much more strict than the
semantics of the DKIM spec, but that it, therefore, outside of DKIM and is
not at all consistent across the industry.
up to the claim of the sender (in the signed From field), and in practice
Having DKIM cover the From: field does not carry any assertion of
authenticity.
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.
However, DKIM is by
far the most common mechanism by which emails are signed, so
I think it needs to be mentioned, though I don't think a lot of detail
is required. Perhaps something like:
The strongest mechanism for providing the authenticity of a message and
its
originator lies only in end-to-end methods involving the message
bodies, such as those that use digital signatures on the original
message (see RFC 1847 [27] and, e.g., Pretty Good Privacy (PGP) in
RFC 9580 [51] or Secure/Multipurpose Internet Mail Extensions (S/
MIME) in RFC 8551 [47]). Signatures applied by the originating MTA
as in DKIM [XX] also provide strong authenticity, subject to the correct
behavior of that MTA.
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.
DKIM's goal is to create a noise-free channel, for a message stream carrying
a domain name in the d= parameter, for much easier reputation analysis. It
does that.
As a side effect -- but only a side effect -- it also provides data integrity
for the covered fields (but no other). That's it.
DKIM does nothing else.
d/
Regards,
John Levine, johnl@xxxxxxxxx, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
