Paul Hoffman wrote:
Greetings again. This follows up on the desire to allow multiple
signatures in the same message.
As a point of order, multiple signatures in the same message work just
fine today. It should be noted that this is a proposal for enhancing
multiple signatures.
This must
be done in a way to prevent bid-down attacks during transitions,
I believe that Mark also has a proposal on the table for how to deal
with bid-down attackes.
and
also must be done in a way so the recipient can unambiguously determine
the order in which the signatures appeared.
The downside of this are MTA's that reorder headers, which they do
unless they know it's a trace header. Which they don't for DKIM
since it's new.
---------------------
Changes:
Add to section 3.5:
p= Earlier signatures (plain-text; REQUIRED if there is already one
or more DKIM-Signature header in the message). This tag lists the
hashes of the DKIM-Signature headers that exist before this
DKIM-Signature header is added, possibly adding the result of a
verification of done by the party creating the current
DKIM-Signature header. The hash is computed using the hash algorithm
that is used in the signing algorithm (taken from the "a=" tag),
using "simple" header canonicalization on the DKIM-Signature header.
The signer MAY include an indication of whether or not a particular
DKIM-Signature header was verified; the absence of this indication
is interpreted by the recipient that the verification was not
performed. The order of the hashes MUST be from the last
DKIM-Signature header in the message to the first.
I really don't understand the benefit of this proposal. We can already
sign DKIM-Signature headers today with h=. Why do we need a different
way, not to mention a REQUIRED different way? If the main motivation is
to be able to transmit "verified" or "unverifed", we have a really big
disconnect. See below.
sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-body
0*( *FWS ":" *FWS sig-p-tag-body)
sig-p-tag-body = sig-p-tag-hash [ "," sig-p-tag-result ]
sig-p-tag-hash = base64string
sig-p-tag-result = "verified-ok" / "verified-failed"
/ "not-verified" / x-sig-p-tag-result
I'm afraid that this is really naive. The verification process
produces *many* more states than two, and we are not chartered
to deal with them cf the auth-res draft. That and I really dislike
the implicit nod to transitive trust from potential adversaries.
Mail is an open sewer, and need to be mindful of creating more
harm than we fix.
Let's not take this on until we're really ready to, ie when we
recharter and take on Murray's Auth-Res draft.
A receiver can always determine the order in which the signatures
were applied based on the "p=" tag. If the tag is absent, that
signature is the first signature on the message. If the tag is
present, the number of hashes in the value indicate how many
signatures were present before this signature was applied.
So a good way to disable a signer is to add the 822 header buffer
overflow number of DKIM-Signatures, right?
A signer applying multiple signatures with different signing
algorithms SHOULD first sign with its most-preferred algorithm, then
with the next-most-preferred, and so on. This ordering prevents an
attacker from removing more-preferred signatures from a message
without the recipient being able to detect the removal.
This has a big problem as far as I can see: how does the receiver
know what constitutes a "signer"? There is no such role that can
be determined on the wire right now. Differentiating off of d=
is not sufficient -- you may have multiple signers in a single
domain, etc.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html