Eric Rescorla wrote:
That said, I think it's important to examine the security
requirements. As I understand it, the major objective here is to use
the presence or absence of the message signature as an input to a
filtering process. Accordingly, unlike with S/MIME, it's not really
critical that people stop relying on a weakened hash algorithm as long
as the cost to forge a signature with that algorithm is
substantial.
Hopefully, the presence of a *valid* message signature will be the
input. I know you meant this, but there has been discussion as to
whether non-verification of the signature needs to be included in the
threats document.
Even if a collision attack is useful for attacking DKIM,
the cost to forge a SHA-1 signature would be quite high (2^61 as of
now), so the probability that a signed message is valid would remain
quite high. Given that the theory seems to be to treat an invalid signature
as nonexistent, this seems like an appropriate treatment to give an
invalid hash algorithm as well. So, I don't see a problem with letting
senders figure out which algorithm to use based on the likely
level of recipient deployment.
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.
I agree with your analysis about how much of a problem SHA-1 is for
DKIM. But as Phill points out, the "marketing" aspect of this is such
that, given all the publicity about SHA-1 breakages, if we continue to
use it some IT manager is likely to say something like, "DKIM is
insecure because it uses SHA-1, so we don't use it." For much the same
reason, I had interpreted SHA-1 as being "algorithma non grata" for new
protocols in IETF, although that's largely an impression rather than
being based on actual statements on anyone's part.
It seems to me that the key requirement here is that if/when senders
start moving to some new algorithm, that we be able to have a
smooth transition. That requires two things:
1. That recipients handle multiple signatures correctly. I.e.,
that signatures with unacceptable algorithms are skipped
rather than creating an error if there is a valid signature.
2. That support for verifying that new algorithm be available
broadly prior to senders starting to use it exclusively.
Agreed.
Given that, I think that we should either:
1. Require SHA-1 and SHA-256 verification support and recommend
signatures with SHA-1.
2. Require SHA-1 and SHA-256 verification support and recommend
(require?) signatures with SHA-256.
3. Require SHA-256 support and forbid SHA-1 in both generation
and verification.
Option (3) seems like overkill. I don't have a strong opinion
between (1) and (2), but probably lean towards (2) on the grounds
that it's better to use something that we don't know has problems,
even probably irrelevant ones.
(2) works for me. But I think we still need to point out how to achieve
compatibility with legacy SHA-1 verifiers, by using multiple signatures.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html