Pietro, Emanuel, Wei,
Pietro's distinction between verifying that a modification occurred and
establishing that the owner of the original From domain authorized it is
the right place to look.
With recipes the signature of the original domain is verified against
the header fields and the body it signed, rebuilt from the ones
delivered, so the message keeps a pass in that domain's name over a
state that is not the state delivered. This holds whenever
reconstruction succeeds, which is the normal case.
Emanuel's second concern already shows why a message-level flag cannot
bound that pass. What an attacker needs is not the content of a message
but a valid signature from a domain worth impersonating. Any recipient
of such a message can rewrite the body and the subject with recipes
while leaving the From untouched, so the message a sender judges
harmless enough to mark okaytomodify is exactly the one that hands over
its domain's authenticated identity. A flag of the donotmodify kind is
in any case a request that any hop on the path can ignore and whose
effect is whatever each receiver decides. Its inverse okaytomodify
inherits the same property.
The Domain Policy Record of draft-ietf-dkim-dkim2-dns-03 shows what a
DNS-published restriction can do. Its strict flag withholds from
subdomains the authorization to make a From in the parent domain
Authentic and it is opt-in, because the default authorizes them.
Withholding authorization from modifications is a different matter. A
record that did so would bring back through DNS the DMARC failures on
mailing list traffic that DKIM2 is meant to end, as Pietro himself
notes.
In my view each pass should be tied to the intermediary at the hop it
refers to. A change to the header fields at a hop can significantly
affect how the message is attributed and disposed of. A change to its
content is attested by a hash, unless its forensic reconstruction is
required through a body recipe. What a node signs attests the passage of
the message through that node: on one side its own verification of what
it received, on the other the sealed attestation and attribution of the
changes it made. No claim can stand that a pass for the original From
attests what that domain never signed. Changes are attested by the nodes
that make them.
Regards,
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
