--On Wednesday, March 26, 2025 19:00 -0400 "John R. Levine"
<johnl@xxxxxxxx> wrote:
> 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.
I agree with Dave and John, but let me add one additional reason:
5321bis is intended to be the Internet Standard version of the spec
for a protocol that is very old (no fundamental changes to the
protocol since 2001 and most of its security implications date from
1982 and changes in 1986, 1989, and 1993 whether discussed then or
not). As a consequence and more important, we should be doing our
best to create a spec that is as stable as possible. If we can look
at another protocol and say "hey, this still evolving", that should
be, in and of itself, more than sufficient reason to keep it out of
5321bis and, to the extent that it should be discussed in either
spec, pushing it into the A/S, which is a new document to be
published as a Proposed Standard. If the A/S has to be updated in a
year or two, that would be unfortunate and, IMO, a big deal, but much
less of a big deal than modifying 5321bis after publication.
That would be just theoretical except that we have an active WG that
was rechartered in the last several weeks with the specific objective
of changing DKIM to deal with perceived deficiencies as described in
the charter and in draft-gondwana-dkim2-motivation. Even if one did
significant handwaving about downrefs, having 5321bis contain a
reference to a specification the IETF has already decided to replace
and change in substantive ways and/or to a document that has not yet
been written seems wildly inappropriate.
Some of the same considerations apply to DKIM (which DKIM?) being
recommended in the A/S but, if there is consensus to do that, we at
least have the possibility of discussing the issues and limitations
and even saying something equivalent to "those who support it should
watch the DKIM WG for substantive changes".
john
>
> 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
