Reviewing the Motivations draft, I believe I'm seeing goals that permit
-- and mostly require -- entirely separate mechanisms.
I've gone into detail (again) below, responding to specifics in the
Motivations draft, but here is a summary:
* A normative practice to have only one recipient per message.
This is needed for O/R signing, but does not need a change to
DKIM, per se.
* A mechanism that permits specifying and protecting originator
and recipient, at each handling site that changes one or both.
This is what DKOR does.
* A BCP specifying what header fields need to be signed. This is
a usage change, rather than a technical change, to DKIM.
* Change-description mechanism, to permit reversal. Completely
independent of DKIM (or DKOR) per se.
Further queries about motivations and justifications for the details of
DKIM2, per se:
This document proposes solving these related problems in a holistic
way, by having every hop in a forwarding chain responsible for:
1. verifying the path that messages have taken to get to it,
including by being able to reverse modifications or by asserting
that it trusts the previous hop unconditionally.
* DKOR provides this, without replacing DKIM.
2. declaring (under protection of its own signature) where the
message is being sent to next.
* Exactly why is this needed?
* And exactly how will it be used?
* And why does it require replacing DKIM?
3. promising that it will pass control messages (including bounces,
abuse reports and delivery notifications) back to the previous
hop for a reasonable time.
There is no way to add these properties to existing DKIM1 in a way
which is both backwards and forwards compatible, so any new
specification will need new headers so that it not mis-interpreted by
DKIM1 verifiers which are unaware of the new specfication.
I've seen some references to why this is useful, but I think the current
documentation does not... document... it. The above claim is clear but
its justification is not. So...
* How and why does this require replacing DKIM?
* Why won't DKOR suffice for this?
2. Some properties that will be required to deliver on these goals
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.
The reason for this control over the destination address seems obvious.
The reason for this control over the return address does not. So...
* Why is this control over the return address needed?
* How will it be used?
... this chain MUST be fully linked in
both directions, with every sending address aligning to the recipient
address of the previous DKIM2 header.
* Again, why is signing the return address required?
To be clear: having the return address be set to a new value, along the
transit handling path, is already common practice.
It will might need refinement and even have this be made normative. But
why does it require that it be covered by a signature?
2.3. A signed bounce format, sent in reverse along the same path
In DKIM2, DSNs are passed back along the same path. This solves the
issue with Email Service Providers (ESPs, entities that specialise in
sending email on behalf of others) wanting error reports.
* How is this different from current practice, at the posting
platform's discretion?
* How/Why does this require replacing DKIM?
The ESP
will see the DSN and, depending on contractual arrangements, may be
able to avoid passing this message any further back along the chain.
As is already true.
Since the DSN messages always go back up the DKIM2 chain, any hop can
strip off the higher number (i=) records; including the sender and
recipient addresses for them, and create a bounce as if the forwarder
itself was doing the rejection. As asynchronous bounces will be
common in DKIM2, this is indistinguishable to the sender, allowing
privacy-preserving forwarders to seamlessly operate.
This seems to presume what information will be included in the DSN.
* This seems to be a modification to the DSN specification, or at
least to its mandated use.
* Where is this specified?
Passing bounces back along the outgoing path also allows mailing
lists to take responsibility for the event and not bother the person
who sent a message to the list.
* Already true.
* How does this require replacing DKIM?
* Why won't DKOR suffice for this?
2.4. A way to describe changes
DKIM2 will define an algebra for describing how to reverse any
changes to create the prior binary data, by inspecting the diff
between the two versions, recipients will be able to see who injected
bad content.
This mechanism appears to be completely independent of DKIM, per se.
* If this depends on DKIM2's version of DKIM, per se, how and why?
* Why won't DKOR suffice for the signing aspects of this?
2.5. Simplification of signed header list
As I noted in my earlier review, this is, at best, a change in best
current practices.
More significantly it appears to have no compelling modification, except
for specifically ensuring a larger set of header fields is signed.
* The reason the larger set of header fields must always be signed
needs to be documented clearly enough to be compelling.
* How will this larger set be used differently from the current,
variable set?
While this part is not strictly necessary to achieve the goals above,
some headers must be signed to get the guarantees
To get /what/ guarantees? From whom? Why are they needed? Especially
if this is "not strictly necessary".
However, some exotic headers may need to be signed for unusual or
future use-cases. DKIM2 will still allow for extended headers.
In spite of the exotic note declaring all sorts of things exotic, the
term has no obvious meaning for this work.
* Even if the word is dropped, there needs to be clear and compelling
reasons for what header fields need to be signed.
2.6. Security gateways
* The term remains undefined.
3.2. Backscatter
...
By requiring bounce addresses to aligned with the most recent
signature domain, we can avoid backscatter, allowing recipients to
always take the message, and later return a bounce.
The logic justifying this claim is not at all clear to me.
* There needs to be a clear, pragmatic, and compelling explanation for
this claim.
* Why will DKOR not suffice for this?
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]
