On 4/11/2025 12:56 PM, Richard Clayton wrote:
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
And it is unfortunate, indeed, that this lengthy stream of comments have
been made against the original document version, rather than the current
one.
That makes the original concerns seem abstract and distant. Which they
aren't.
And the pattern of responses serves further to defer actually dealing
with the concerns.
> btw, the return channel is always asynchronous. Arguably even
direct, single-
> hop is asynchronous, since the user client is almost certainly not
connected to
> the process.
For clarity we could say "a NEW asynchronous return channel"
New vs. old is irrelevant.
The model of sync vs. async appears to be based on a very restricted
view of how mail flows, where ´'sync' sees to require a 1-hop model.
An error during the SMTP session can and does often generate an 'asynch'
behavior.
>> 1. Background and motivations
>>
>> In 2007, [RFC4871] (Domain Key Identified Mail / DKIM) was
published,
>> outlining a mechanism for a domain to sign email in a way that
>> recipients could ensure that the email had come from an entity
>> possessing the secret key matching a public key published in
the DNS
>> by the source domain. For clarity in this document we call this
>> established scheme "DKIM1".
> *Again, the defined semantic of DKIM is not to ensure who a message
> 'came from'. This confuses common practice with design. *
> It is to identify an entity that takes 'some' responsibility for it.
To be ultra-pedantic it merely shows that an entity with a copy of the
private key has been able to acquire a copy of (most of) the email which
has now come into your possession...
Since this confuses what with how, it is not merely pedantic.
DKIM states its semantics. Focusing on the mechanics distracts from the
statement of intended semantics.
The new drafts state a very different semantic, demonstrating a very
basic misunderstanding of what DKIM does and does not do.
And since I've posted text to that effect multiple times, it is odd that
this point continues to be ignored.
In fact RFC6376 expresses this in a different tense "permits [...] to
claim responsibility" and the conditionality is I think wise.
*The string ¨to claim responsibility" does not appear in that document. *
The string that does appear carries an important difference in
semantics. The issue is not about tense but scope.
> This is very different.
> *And the difference is important because an email can get touched by
> a lot of entities, each of which might provide a DKIM signature.*
I am sure that we can settle on some wording (perhaps by copy paste)
that describes DKIM1 appropriately.
Perhaps we can settle, now, on the actual job that DKIM does and does
not do?
> Like the rest of the email architecture, the design of DKIM is much
more
> flexible. And this point of confusion sets the stage for an
approach to email
> that is much more constraining than email is designed to be. The word
> Procrustean is apt.
> A casual dismissal with a comment like 'things have changed' is the
usual
> response to this point. Unfortunately it mostly reflects a lack of
effort to
> consider tradeoffs, or to embrace the historical IETF bias to retain
as much
> usage flexibility as supportable.
>> This document has been obsoleted and updated many times since then,
>> and a large amount of operational experience has been gained using
>> it. However, it has some known weaknesses with some kinds of email
>> flow.
>>
>> If an intermediary alters the email then the original DKIM1
signature
>> will no longer be verifiable.
> This is not a 'design weakness'. DKIM was intended to survive
simple, classic
> MTA-based relaying, but it never had a goal of surviving
re-postings. It does
> what it was designed to do.
I tend to agree ... weakness is probably not the right word for "it
breaks completely".
Drive a car over a speed bump at speed. It's designed to deal with
that. Drop it from an airplane and it breaks completely. Or perhaps
saying that is, forgive me, silly.
Saying that DKIM breaks when it is used differently than intended
misdirects discussion.
And to be clear, my point is not that there is nothing to be done but
rather that claiming DKIM is a problem is simply wrong.
And, by the way, you group's effort to create something completely new
supports this point. (re-using component tech from DKIM does not make
it a variant of DKIM. Especially since the semantics of what is being
pursued are so fundamentally different.
Why not say that the problem is those mailing lists that modify the
message? Because, of course, they aren't. Neither is DKIM.
No-one is suggesting that the impact of, for example, mailing list
alterations to email were unforeseen (and indeed l= is present to try
and address the issue).
> Re-posting a message can entail arbitrary transformations and a
technology like
> basic digital signing never had a goal of surviving that. DKIM was
/explicitly
> NOT/ designed to survive these transformations.
> While there is nothing wrong with seeking to provide a mechanism
that does
> survive, it is a new requirement, not a failure in an existing
mechanism.
> So the wording here is finding fault with something that was not a goal.
> Using language that implies or claims failures, for things that were
known at
> the time and were deemed acceptable or out of scope is not a failure.
> Especially not after roughly 20 years.
> *What the above language actually implies is that this new effort
> represents a substantially larger and more ambitious goal. One for
> which I believe there is little or no technical history and
> certainly no operational history.*
> This lack of experience with any mechanism -- other than a basic
email object -
> -
> that works through multiple postings/deliveries makes this aspect of
the design
> goal an open research topic.
> And there are no ready proposals that have been developed and
discussed and
> converged on, ever since the expansion of DMARC use created a
problem for
> multi-
> posting/delivery sequences. /That's quite a few years without
landing on a
> concrete proposal./
> *Surviving arbitrary manipulations that might take place, when going
> through delivery and re-posting, is another open research topic.*
Interesting that none of the above observations prompted any response...
> *Trust is an entirely separate and challenging line of reputation,
> etc. (research) work.*
These points appear to be commentary on the task being taken on, rather
than on the documents or the design which we outlined. As such I think
they are overtaken by events since we now have a chartered Working Group
If only the current draft did not continue with repeated, casual use of
the word 'trust'...
So, maybe not overtaken by events.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
