Dave Crocker wrote in
<[email protected]>:
|This revises DKOR to use a single header field, and to support the
|addition of that field at each handling node along the way.
|
|The draft has fleshed out both technical and documentation details quite
|a bit. Also, it uses the alternative draft naming scheme, as requested.
I thought the language is fantastic. But the entire thing is
a technical problem that does not solve any.
- Not talking about sequence numbers not being linked etc. ...
I have not understood which (how many) existing DKOR headers
should be included in their signature.
- Not talking about legal state of permanently revealing RFC 5321
SMTP envelope data in the email RFC 5322 IMF message.
- Not talking about the still missing necessary caches to protect
against replay.
- In the current email world, DKIM-Signature often get removed aka
mitigated away. Until covered (to be also removed) dangling
DKOR headers will remain. (Unusable since not cryptographically
verifiable.)
This means that sequence numbers cannot be trusted.
This means there is potential that several combinations may
have to be tried to find the correct DKOR header for
a DKIM-Signature, dependend which hop mitigated "what" and
"how much". Or one can simply use "the last" DKIM-Signature
and DKOR headers, anway. What for, sequence numbers?
(Effectively i think including the sequence in the
DKIM-Signature is a must.)
- It does not make technical sense to include SMTP envelope data
beyond the "recipient hop". In S->A->B->R, if R expands an
alias or is a MailingList that reposts, former SMTP envelope
data has nothing whatsoever to do with the message.
DKIM links a RFC 5322 message to a domain. In S->A->B->R none
of A and B are supposed to modify the message. R may cause
changes (alias expansion, ML tags and header additions), and
then send the message further on.
DKIM v1 always failed that "next" message until the DKIM
covered part remains unchanged, or until R mitigates the IMF
From: header which DKIM v1 takes special interest in.
Anyhow, except for asynchrous alias bounces (huh???), no
former SMTP envelope makes sense to be included in that "next"
message since delivery problems at recipients addressed by the
"next" message can aka must only be reported to, and dealt
with by the domain which sent the "next" message.
- *If* there is desire be able to "undo" an alias expansion
"later" to redirect the "bounce", VERP ("as via SRS") is the
much better, the *only* approach, compatible to anything, and
actually in real-life use for decades (via non-standardized
SRS), today even an absolutely necessary precondition to survive
RFC 7208 SPF checks.
If software starts to throw away DKOR accompanying its
(stack-)referenced DKIM-Signature, that DKOR information is
lost for this purpose anyway.
- Later undoing will likely break for DKOR as it does not offer
undoing message adjustments in a cryptographically verifiable
way at all. At which point either all the elder data is lost,
bogus and dangling, but anyway totally useless.
- It is technically false to claim that single-recipient is
necessary. It may be so *if* a dumb software creates
a signature "out in the blue". For example, in order not to
reveal Bcc recipients to the world.
Here i want to point out one thing. DKIM v1 as it is and you
propose unchanged for DKOR will look for the IMF From: content
but/and likely start multiple happy-eyeball caused DNS lookups
for multiple DKIM-Signatures.
Claim: DKIM v1 as it stands is an excessive DNS user on the
verification side. It makes sense for multiple reasons to
introduce a single DNS lookup on the signing side if that
mitigates the greediness of the verifier per se.
It is not true because only software which understands the
iterated DKIM will be able to use it to protect against replay
et cetera.
It is thus not true in a mutual agreement situation where
a Sender asked the Recipient whether EDKIM support is available,
in which case the Recipient can remove the according data, which
will as such be useless shall the message be sent further on.
In a S->A->B->R case, none of A or B could replay a message
with AC[DC] to any other recipient but the ones at R.
Granted AC[DC] as it is does not offer any replay protection
*unless* the Recipient domain supports EDKIM.
This means that A and B cannot protect themselves even if they
do, and that S must live with potential misuse.
ACDC could be changed to always include a subsignature, but
*then* it still can create one message for all To:/Cc:
recipients at domain R, it only would have to become single
recipient each Bcc: recipient.
*That is still much better than being single-recipient all
the time!*
Note that this permanently reveals SMTP envelope data, for
which no legal advise exists.
That MAIL FROM was not included in the per-recipient-domain ACDC
subsignature from the start was an error. And if only to avoid
that in S->A->B->R modifications happen undetectedly and bounces
go back to wrong addresses.
Also, and still, an iteration would make it a SHOULD to set i= in
the DKIM-Signature; this *can* mitigate that elder SMTP envelopes
no longer exist, shall the very original sender be interested to
make this link. (To note that ACDC includes DC and so changes can
be unrolled and cryptographically verified, and then the IMF From:
content is available; but having i= can make sense, and accessing
it is cheaper than unrolling.)
By the way.
I also claim that EDKIM does not only need a replay cache on the
verifier side, but also a bounce cache on the signer side.
In that EDKIM should apply VERP if the signer detects alias
expansion conditions, it should de-facto act like SRS.
This is because even if all of your DKOR would be fine and nice,
there is SPF and this does not survive a hop, and the IETF does
not offer anything to deal with that, rendering its other things
broken in the wild.
And because we only have 45 bytes before base64 encoding we cannot
simply use VERP-in-VERP-in-VERP.. over and over again! Eg (this
also includes IMF From: mitigation which i would like to introduce
so receivers, for the first time, get a notion!):
[email protected]
[email protected] via ML <[email protected]> REPLY-TO if not yet
[email protected] via ML via [email protected] <[email protected]> [NO REPLY-TO]
[email protected] SHOULD use Author:
[email protected] via A1 <[email protected]> [NO REPLY-TO]
[email protected] via A1 [edkim[+a=b.c]@e.f] via A2 <[email protected]> [NO
REPLY-TO]
No, it can only create some random and MAC protected UUID (like
SRS), but with a single real component in order to properly bounce
back to original senders such messages. And if the lifetime of
that cache entry has passed, it can only bounce the bounce and
state "your message is too old, maybe try to contact XY
directly?", and there XY would be the VERP-decomposed single real
address; which thus likely would be the last sender (before this
hop which resent).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
