Barry Leiba wrote in
<calaysj+jfl2edm0mhs+fcc2wjb6b5s1jbee_7rcudvzc3s-...@mail.gmail.com>:
|It's pretty well established that trying to reconstruct a message
|based on a validation failure is a bad practice. If a mailing list
|wants to play well with DKIM, it can add its own signature and sign an
|Authentication-Results header to say that it validated the original
|(or use ARC for that). Barring that, a failed validation really needs
|to stay a failed validation, and the receiving domain shouldn't be
|guessing what might have happened and trying to reverse it.
Ok. Given this is a fact.
Because in the end noone would like to duplicate all the headers
(that have changed) plus the body etc, even comprimized, on each
station anew, to be able to track it all the way down to the
originator.
But why is ARC, or DMARC necessary at all?
Why all this data duplication?
Why the invention of stack addressing via indexes, instead of
simply taking it as the stack that it is?
What fundamental would be missing if there would be
1. DKIM-Store: header.
This header has no meaning except being defined as "should not
be seen on the internet", meaning "should be removed on
ingress" as well as "should be removed on egress".
It is just a suggestion how to pass information from the
ingress side to the egress side.
For example, it could be used to store the entire, readily
prepared for signing, DKIM-Signature content, meaning headers
as well as the halfway done signature itself, thus including
the message disgest of the body.
(Though likely encrypted with a host specific key, so that
users only see a base64 encoded binary blob.)
Of course users could remove this header, breaking the
machinery. But this is true for ARC, too.
The content could also be stored in a DB for some time, instead
of being passed along as part of the email itself, in a format
totally different, and not as a "DKIM-Store:".
2. A new DKIM flag "V".
This means that on the ingress side the DKIM signature was
verified successfully.
The egress side (DKIM signature creator) will get a notion of
that in an unspecified way, but very likely through the
DKIM-Store: header. It will set the "V" flag accordingly.
[
3. A new DKIM flag "S".
This means that on the ingress side the SPF of the sender was
verified successfully.
The egress side (DKIM signature creator) will get a notion of
that in an unspecified way, but very likely through the
DKIM-Store: header. It will set the "S" flag accordingly.
I put this in brackets because i personally see no normal
reasoning for SPF in an environment with a "hard-DKIM",
meaning that signatures must verify successfully.
Because you do not have SPF for TLS, for example.
If the key cannot be verified, you quit the connection.
Also SPF breaks any forwarding, it does not survive the
first hop.
But of course i see that people use it and like it, and it
protects against key misuse, especially in a world without
DNSSEC and "hard-DKIM".
]
4. A new DKIM flag "M".
This means that the DKIM signature creator recognized that the
message has been modified in between the ingress side and the
egress side. For example, headers were modified, or the body
digest is no longer the same.
The "M" flag means that performing a DKIM verification on
"elder" DKIM-Signature: headers will fail.
"Elder" means, further down the received: etc trace stack.
These could also be "B" and "H" flags, to notify specifically
changes of body and header(s), respectively, but i do not think
so, as it is useless cruft.
The egress side (DKIM signature creator) will get a notion of
that in an unspecified way, but very likely through the
DKIM-Store: header. It will set the "M" flag accordingly.
It seems to me the above replaces all of ARC and the
Authentication-Results: header as such.
What is missing? Gimme three steps!
XX.
DKIM-Subsignature mechanism as described on this list maybe up
to two years ago, meaning that
1. DNS lookup for a new TXT-like record that signals "this host
DKIM signs its emails"
2. .. meaning a missing DKIM signature is "an attack"
3. .. meaning the DNS content includes a key that can be used
for encryption
4. meaning message receivers are sorted into destination hosts:
To: u1@h1
Cc: u2@h2
Bcc: u3@h2 u4@h3
5. resulting in
DKIM-Subsignature: d=h1; [ENCRYPTED:] u1
DKIM-Subsignature: d=h2; [ENCRYPTED:] u2 u3
DKIM-Subsignature: d=h3; [ENCRYPTED:] u4
headers to be created.
However, these subsignatures are not placed in messages as
such, but the message in spliced into three on the SMTP
level, and each host will get the version with its specific
subsignature.
(This splicing is a bit unfortunate but does not reveal Bcc:
content at all, at least the size could be deduced.)
OR
..
3. .. meaning the DNS content includes the currently "most
desired" domainkey, so that further lookups are not needed,
*unless* on selector= mismatch
..
5. resulting in
DKIM-Subsignature: d=h1; u1
...
...
P.S.: in this version the splicing also prevents the hosts
from seeing Bcc: users of each other (in clear).
It seems to me the above replaces all of DMARC as well as
draft-chuang-replay-resistant-arc.
(Of course =reject only; one may add some specifics to the new
TXT DNS record to fill on possible statistical or report holes,
but the lesser the better i would claim.)
--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 -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
