Section 1:
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.
First off, "unconditionally" seems like a very strong word especially
wrt "trust". The problem is that I'm not sure what it has to do with
anything. An intermediary can already resign a message, and receivers
can make of that what they will.
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.
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?
There is no way to add these properties to existing DKIM1 in a way
which is both backwards and forwards compatible
This is debatable to say the least. As stated it just a bald assertion.
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.
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.
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.
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.
2.5. Simplification of signed header list
What is the point of this? What problem does it solve?
DKIM2 headers will always have timestamps so that "old" signatures
have no value.
There already is an x= option with DKIM, so I'm not sure what's different here.
A possibility to be investigated during testing is a "singleton" flag
to allow senders to specify that this is a message for a single
recipient (e.g. for authentication codes for billing transactions)
and should not be expanded by mailing lists.
Not sure what this has to do with DKIM. Assuming it's useful at all, it
could be its own header which could be DKIM signed as usual.
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.
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.
TL;DR there are a lot of assertions here that lack any justification or
show causality (re: replays). There also seems to be the high likelihood
that various completely legitimate uses of email would be a casualty of
this, and the (unintended?) consequences have not been enumerated or
considered. Finally, even at face value I do not see what would preclude
extending DKIM itself.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
