(Apologies for the delay in responding. Extended and draining travel
and a broken laptop got in the way.)
Bron, et al,
Thanks for this note, which engaged with useful detail and provided
useful scenario data to consider. We need more scenarios.
Also, on reflection, I've come round to the view that it will be useful
to explicitly support a chain of signatures along the transit handling
path, with annotations that indicate the order of the chain. The next
draft of DKOR supports that.
Inline...
On 4/26/2025 1:51 PM, Bron Gondwana wrote:
For succinctness I shall call your proposal DKOR and ours DKIM2 below,
acknowledging that the name DKIM2 does not have consensus.
On Sat, Apr 26, 2025, at 13:07, Dave Crocker wrote:
On 4/25/2025 8:13 PM, Bron Gondwana wrote:
On Fri, Apr 25, 2025, at 12:31, Dave Crocker wrote:
HTTPS followed an incremental adoption path, not all that different
from what I've proposed, since there is utility for any pair of
client and server that adopted it. This is profoundly different from
your proposal.
I disagree with your "profoundly different" assertion here. DKOR is a
strict subset of the capabilities provided by DKIM2. DKOR provides
benefits as soon as both a single sender and a single receiver
implement it, for direct mail flows between those two systems.
*DKIM2 also provides immediate benefits* as soon as two systems
support it, for direct mail flows between those two systems.
As offered, DKIM2 requires massive infrastructure adoption, before being
useful.
That is, it has so far only been offered as a single, integrated,
take-it-or-leave-it set end-to-end infrastructure changes. In fact I
pressed for divide-and-conquer thinking about this effort and it was
been repeatedly and vigorously rejected.
To the extent that adoption by just two end systems can achieve benefit,
I believe there has been nothing said or documented to support that.
It's not that I'm disagreeing with your claim. It's that I don't see how
it is true, given what has been said, so far.
Also, it's not that I disagree that DKOR can be viewed as a subset of
DKIM2. It's that there has been no sense of how to operationalize a
sub-setting of DKIM2, nor does the documentation support doing that.
Both systems provide much less benefit if messages flow indirectly
through a forwarder or mailing list that is not participating.
Less is not the same as none.
DKIM2 provides an upgrade path where when the intermediate systems are
upgraded to support DKIM2, every hop of the pathway is DKIM2 and you
can eventually start requiring a full DKIM2 pathway to accept mail
from more sites. I can anticipate a future DMARC-style technique for
publishing a DNS record saying "do not accept messages from this
domain that have exited the DKIM2 ecosystem at any point".
Consider the likely, and long-term, reality that only /some/
intermediaries adopt it. How will that look, in terms of actual efficacy?
And I'm suggesting the consideration be in terms of detailed scenarios,
not just broad, generic reactions to the idea.
DKOR, by my reading, can never reach that endpoint by itself.
When something makes no effort to do a thing, it's misleading to claim
that it cannot 'reach' that thing. It is declaring a failure to reach a
goal that does not exist, except as a post-hoc, externally-imposed thing.
Stylistically, it is of course fine to say that what it is trying to do
is not useful or is insufficiently useful, but these need to be
explained in detail, rather than just asserted. Especially when the
thing being criticized is not being offered as the only path to pursue..
DKOR has a more modest goal than DKIM2. As you note, it is a subset.
If that subset of DKIM2 can, in fact, be considered as a real-world,
operational subset, then let's do that and compare just that portion of
DKIM2 with the same scope and goals as DKOR.
And there is nothing about DKOR that is meant to limit pursuit of
/additional/ and complementary mechanism. Independently.
I agree that it's a potential stepping stone in the right direction,
but by itself it's not sufficient.
ack.
Our approach solves the whole problem enough to be worth the effort.
You keep saying that. I keep asking for detailed scenarios that show
how. You then keep coming back witht he same, generic claims.
OK - let's suppose that I had DKOR headers on this email.
Presumably my system would send two messages with DKOR headers; one
MAIL-FROM:[email protected]
RCPT-TO:[email protected]
the other
MAIL-FROM:[email protected]
RCPT-TO:[email protected]
...
It's unclear from your draft whether the IETF mailing list server
is expected to add its own MAIL-FROM and RCPT to headers to each email
or not, but regardless...
The mailing list is re-posting mail. A new submission. It can do
whatever it wants.
Except, of course, it must use new RCPT addresses, since that's its job.
Whether it specifies a different Mail-From varies, but it is a common
and reasonable thing to do, since the originating site can't do anything
about delivery problems for addresses used by the mailing list.
Making this a BCP-based normative requirement -- I'd suggest SHOULD
rather than MUST, just to deal with scenarios that don't need a
different address -- would be reasonable.
But note that neither of these has anything specifically requiring a
change in signing technologies.
Nor does a SHOULD that the mailing list add its own signature.
there's no way for Gmail to know - if this was a spammy message,
whether the spam was generated by me and sent to the IETF list, or
whether the IETF list was a bad actor. It would need a reputation
database. You've basically re-implemented the same problems that ARC has.
I'm going to claim that this is required, no matter what underlying tech
is used.
Any scenario that matches on simple, objective, non-obvious criteria for
spamminess might involve a message that is actually legitimate. Feel
free to provide an analysis that comprehensively shows otherwise.
However, to date, after some decades, I think we have not seen it.
With DKIM2, the second message would have on its copy from me:
|DKIM2-Signature: i=1; mf=||[email protected]|
<mailto:[email protected]>|; rt=||[email protected]|
<mailto:[email protected]>|; d=fastmailteam.com|
And then on its copies from the mailing list:
DKIM2-Signature: i=2; [email protected]; [email protected]; d=ietf.org
DKIM2-Signature: i=2; [email protected]; [email protected]
<mailto:[email protected]>; d=ietf.org
DKIM2-Signature: i=2; [email protected]; [email protected] <mailto:[email protected]>;
d=ietf.org
etc. Each with a separate signature, so they would be clearly not
just a replay of a single message which was directed at the mailing list.
After reviewing this a number of times, over the last month, I've come
round.
First, to the goal of supporting a chain of signatures and second to
having the signatures label the sequence.
On the numbering sequence, it might seem obvious and trivial to add, but
it's use involves an extra bit of analysis mechanism and even trivial
stuff can get tricky, in the considerable scale and complexity of highly
distributed and independent implementations and erratic adoption. But
overall, I'm sufficiently swayed to include it in the next version of DKOR.
Even more importantly, they would have delta header fields:
Or not.
Or, rather, they /might/ not. And for a very long time, probably won't.
But that can be ok, unless an artificial dependency is created. Much
like DANE did with DNSSec. The dependency is strictly operational, but
it was written into the core DANE specification and constituted a
show-stopper for adoption.
In technical and even operational terms, the delta mechanism is fully
and completely independent of the signing methodology. Signing needs to
cover the delta header field, but that's a mild operational convention,
not a technical design integration.
To stress this point: The delta mechanism can be and should be pursued
independently of any changes to the signing tech.
Use it when it is ready to be used, but don't depend on it, for now.
Yours brings some benefit, but the overall benefit is trivial
So, making it easy to detect DKIM Repaly is a trivial benefit? Wow.
If it detected DKIM Replay in the general case, it would not be
trivial - however it only detects DKIM Replay in the direct case.
Given that Replay is about actions involving an intermediary, I don't
know what direct vs. indirect means.
In any event, yes, there are legitimate scenarios that match Replay
abuse scenarios.
And there always will be.
So, yes, there is more needed to assess the difference. However I think
the view that this is somehow amenable to perfect assessment by strictly
objective, mechanical means is wrong and misguided, based on the
industry's experience over three decades.
It's still not possible to distinguish between an alumni forwarder and
a DKIM replay; short of keeping a database of every alumni forwarder
that points to you, and at scale that's decidedly non-trivial.
We've seen an example of using a Microsoft intermediary to commit DKIM
Replay spam.
Every technical aspect of that looks to be legitimate. But the
operational practice was not.
because it doesn't close the forwarding hole and forwarding becomes
even more of a poisoned chalice than it has already become (Wei
showed evidence of this and a credible theory for why).
Scenarios, Bron. Show yours working in detail for all this extra
benefit, so others can a) evaluate what it will take to adopt it, b)
evaluate its likely efficacy, and c) consider being able to use
different components that might have superior characteristics.
See above a worked example. I'm happy to do more examples if that's
still not clear enough.
Yes, please.
I think ones that might be especially helpful would deal with paths that
have only partial adoption.
This is my objection to your proposed approach. It's both trivial
in its implementation, and trivial in its benefit.
Again, saying that making it easy to adopt and easy to use and
effective for finding Replay is a trivial benefit seems really quite
surprising.
I reject the assertion that DKOR will be effective for finding
Replay. It is indistinguishable from alumni forwarding or mailing
lists, and provides no upgrade path to make it distinguishable.
Your rejection appears to be predicated on the view that I suggest DKOR
be the only action taken. But it isn't.
I am suggesting it as an upgrade to signing activities, where the
upgrade is compatible with existing DKIM, rather than requiring a
replacement of the global DKIM infrastructure.
Preserving an existing, widely-adopted, and useful infrastructure is not
a small benefit. Adding enhancements that rely on it and, therefore, are
compatible with it -- ie, enhancements that represent incremental
benefit -- are especially worthy.
And the cost of replacement is pretty much always much bigger, in terms
of time, money, and effort, than is estimated. Advocates are pretty
much always wildly optimistic about the expected rate of change, when
compared against what actually happens.
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]
