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
