Jim Fenton <fenton(_at_)cisco(_dot_)com> writes:
Eric Rescorla wrote:
Jim Fenton <fenton(_at_)cisco(_dot_)com> writes:
The "figuring out" of which algorithm to use is the central problem
here. There just isn't a good way to do it, which is why my text
suggested the use of two signatures. The verifier only needs to verify
one of them, and can decide which hash algorithm to use for the
verification early in the receipt of the message. I'm less concerned
with burdening signers than verifiers.
Certainly, I agree that when transitioning from algorithm A
to algorithm B you need to temporarily sign with both A and B.
The question is to what extent we are transitioning from A
to B. E.g., if we do anything to break existing signatures,
then there's less point in running SHA-1 in parallel since
the signatures won't work anyway and we can just tell people
to deploy SHA-256 verification with the new canonicalization
or whatever.
I can't think of any reason that we would break existing signatures
without some observable change in the DKIM-Signature header field.
Either a change in some parameter (such as the change in
canonicalization algorithm names between allman-00 and allman-01) or an
increment in the version number. I consider such a change equivalent to
a change in the hash algorithm from a compatibility standpoint: we
could run the old and new versions in parallel as separate signatures.
Totally agree. My point was merely that there's no need to run the
combiatoric explosion of canonicalization and signature algorithm.
When you rev the canonicalization/version number you can rev
the hash algorithm as well--or not. There's no legacy issue for
SHA-1 support with new canonicalization algorithms.
That said, why are you less concerned with signers than verifiers?
RSA signatures are much faster to verify than generate (about 20x)
so even messages destined for a fair number of people tend to
burden the signer more. And, of course, the verification load is
likely to be more spread out....
A single message destined for a fair number of people would only be
signed once, since we aren't signing the envelope addresses.
Yes, I know that. That's why I said that *even* messages destined
for a fair number of people....
The reason
I'm more sensitive to verification load is the potential make-work
attack from an attacker who generates valid-looking but invalid
signatures (which are effectively free in terms of computation). This
is described in more detail in section 4.1.6 of the threat document.
I don't understand why this is a relevant consideration for whether
we *require* signers to do multiple signatures or not at this time.
In order for transitions to work properly, verifiers must be able
to process multiple signatures, so an attacker can exploit this
whatever the behavior of any individual signer.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html