On 3/5/25 5:52 PM, Allen Robinson wrote:
2. declaring (under protection of its own signature) where the
message is being sent to next.
Assuming this means copying the rcpt-to in the 822 message, that
doesn't require any modification to DKIM itself. There is no
necessity that it be part of the signature block since it could be
an independent header, though it may be more convenient to do so,
but that would just require an upgrade to DKIM, not a replacement.
I do think it's worth considering if there are alternative transport
mechanisms for the information DKIM2 wants to convey along a message's
path to its final destination. The people working on this largely
don't believe DKIM+extra headers is workable, but declaring that it's
impossible (or possible) before we even know what we're trying to
transport seems a touch premature.
Well, this draft is definitely taking a position on that. The authors
are more than welcome to not take a stand, imo.
3. promising that it will pass control messages (including bounces,
abuse reports and delivery notifications) back to the previous
hop for a reasonable time.
Again, I'm not sure what this has to do with DKIM. And which
"previous" hop? The previous hop as evidenced by received headers,
or previous hop as evidenced by signatures? What is the purpose of
this? And what does "reasonable time" mean?
Previous hop here refers to the previous DKIM2 signer. Every system is
expected to add a DKIM2 signature declaring that it handled the message.
Why is this better than the current practice of sending it to whatever
is in the 821.From address?
What does it have to do with DKIM? Mostly having a
better-authenticated place to send the notifications, which as you
mention is already sent.
Why does authenticated or not matter? Again, none of this is obvious to
me. Maybe it's just me, but maybe it isn't.
By only allowing precisely one destination address per DKIM2-signed
email, and encoding that address in the signature, messages will be
unable to be replayed to any other destination.
There is no explanation of cause and effect here. Is a receiver
supposed to say a signature is invalid if the rcpt-to in the SMTP
conversation is different than the rcpt-to in the signature? If so
you've now broken the forwarding ability of DKIM and a completely
legitimate use of email in general.
Yes, the expectation is that the RCPT TO matches what's in the most
recent header. This doesn't break forwarding as the forwarder would
add a DKIM2 signature to indicate that they did the forwarding, and
that would contain the new recipient address.
It invalidates the originating signature though (actually all of the
previous with different rcpt-to). This seems at odds "mutation" goal too.
As for effect, there's little value in sending the same message a
billion times to one address. There is significant value in sending
the same message to a billion different addresses, and that's why
replay is a problem.
Here is my thinking. What's wrong with it? I am a spammer using an ESP:
1. I craft some spam and I test it across a range of anti-spam filters
(or just gmail's) and voila, I find one that will pass their filters
2. I then take that message and send it to my list of recipients. I can
use rcpt-to bunching or not. If I do a single rcpt-to per, I will have
to resign my spam for each recipient, but that doesn't seem like an
onerous requirement. I might grumble about it, but in the end of the day
I -- the spammer -- will do what is necessary.
The essence is that the message content got past the filters. Whether it
has to be done one-by-one or in batches seems like an operational issue.
In any case, I think a larger problem is that to my knowledge the draft
doesn't even define the scenarios in which "replay" is a problem, so if
that's not the right scenario, that's on the draft because it doesn't
lay the problematic scenarios out.
2.2. A chain of aligned DKIM2 signatures over SMTP from/to pairs
If the recipient wishes to forward the message on to another address,
it must apply its own DKIM2 header, signed by a key which is aligned
to the domain of the recipient address in the previous DKIM2 header,
and with a bounce address which is in the same domain.
I don't know what "aligned" means. And DKIM keys have nothing to
do with the recipient. If that is a new requirement, it would be
good to know why. If it's just an operational issue that can
already be done with DKIM now, it would be good to know that too.
Not well-defined here, but for early discussions think of it as
conceptually similar to DMARC's identifier alignment.
Align what with what?
The description is a bit wordy. A concrete example is if the first
DKIM2 header says the recipient is [email protected], the second DKIM2
header should be signed by something aligned with foo.com
<http://foo.com>, and the MAIL FROM tag in that header should have
alignment with foo.com <http://foo.com> as well.
I've tried several times and am not getting it. What if the intermediary
is not the originating domain? It won't have keys to sign for foo.com.
And it certainly won't have keys for the rcpt-to domain.
That and it makes me nervous about intermediaries that change the
mail-from -- like mailing lists to they get the bounces not the originator.
The end result is, like ARC, a chain of domains which have handled
the message; however unlike ARC, this chain MUST be fully linked in
both directions, with every sending address aligning to the
recipient
address of the previous DKIM2 header.
Why is this useful? I don't know what "fully linked" means either.
And what happens if it passes through a domain that doesn't resign
it? It's really hard to understand what the point of this is.
Fully linked here means that every signature header's from address has
some relationship to the previous signature's recipient.
I'm sorry, I don't understand this at all. Which from address? And what
exactly is the utility? What problem is being solved?
This is yet another example that makes it plain that the authors have
some model in mind, but the draft doesn't state it so the rest of us are
left in the dark.
Interop with non-supporting systems is certainly an area that will
need further thought. Particularly because it will look very similar
to malicious alteration or replay.
2.4. A way to describe changes
Since this is a "motivation" draft, it would be to now what...
motivates this. Also it seems to conflict with the requirement
that mismatched rcpt-to signatures should be
ignore/invalid/whatever. That is, I could reconstruct the
canonical text for the original signature, but if the rcpt-to is
different from the signature it ought to be rejected on those
ground. Or something.
Being able to undo changes allows verification of every signature
along the chain, if one were so inclined. The most interesting is
probably getting back to the originator's content but there could be
uses for verifying intermediary signatures as well.
But the originating signature would still fail on the rcpt-to grounds,
right? That is, a mailing's subscribers addresses is not going to match
the rcpt-to of the original signature as an example.
Again, clarity of what happens when the rcpt-to in the 821 conversation
doesn't match the rcpt-to in 822 message is needed. I don't think it
mentions what that means.
2.5. Simplification of signed header list
What is the point of this? What problem does it solve?
I think this is an opportunistic simplification based on operational
experience, and not a hard requirement for DKIM2 to work. One could
easily envision a version of DKIM2 with exactly DKIM's handling of the
signed header list.
As Dave alluded to in his review, there's considerable evidence that we
don't know of one particular set of headers that should be signed. And
the way it is in DKIM is a feature, not a bug in any case. It allows new
(or old) headers to be signed without changing the protocol.
I would just drop this completely, especially it's not part of the charter.
If the
email has been duplicated then recipients can assign a reputation to
the entity that did the duplication (along with the expected number
of duplicates that will arrive from that entity) and assess
duplicate
signatures on that basis.
I'm pretty sure you can do this already. But reputation is
definitely out of scope.
There are heuristics for detecting replay. One of DKIM2's effects is
that the detection becomes easier because you have a verifiable chain
of custody for the message.
That's what I'm not getting. How?
4.2. Reducing crypto-calculations
The irony here is palpable. The easiest way to "reduce
crypto-calculations" is to not invent a new protocol, but upgrade
the current one. And of course there is no requirement the
receiver verify any signatures at let alone all of them, so I
don't know what the point of that is.
I'm not sure how your proposed extension of DKIM approach would result
in less crypto than what is proposed in DKIM2, as even if it were
DKIM+extra headers the protocol would still require signing at every
intermediary system.
Well, if it's a DKIM upgrade rather than a new signature it will be one
less assuming the DKIM signature is still required which I can envision
any world in which wasn't.
Having a goal of minimizing the computational, network, and storage
cost of the new thing seems like a good idea. Maybe minimize rather
than reduce would be better though? If we happen to reduce cost,
great, but if we fail to reduce that's probably also fine as long as
we decided the extra cost provides value.
Well, Google doesn't seem to be too worried about it with two ARC
signatures and some weird X-Google-DKIM-Signature. Frankly I'd just drop
this line of thinking: any performance gains are going to be on the
margins.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
