Dave CROCKER wrote: > > Barry Leiba wrote: >> 1. Crypto suite X had been seriously cracked, such that an attacker >> could, at least in some cases, create a valid suite-X signature on his > > Is there any experiential basis to motivate our having to worry about this > attack vector? In other words, do we have good reason to believe that this > threat vector is significant?
I think this one's a yes - given the developments with hash collisions in the last few years. While DKIM signatures are much more ephemeral than other kinds (e.g. signatures on certificates) I think we should still be concerned about this. There's also a non-security reason here, the NIST recommendations and hash competition (that various folks will follow) do mean that we are very likely to want to migrate from rsa-sha256 to rsa-sha3 (or maybe something ECC based) within the next few years. So we should try to make that transition easy (or at least not make it hard). > Is there a history of worrying about this attack vector, among other efforts > to > do standards work with similar technology? In other words, are we the only > ones > worrying about it, or is this a common concern amongst experts? Yes. TLS authenticates the ciphersuite negotiation via the final handshake message. Less convincingly, there was a huge effort to get negotiation right for GSSAPI with SPNEGO and S/MIME has its capabilities stuff. Bidding down attacks are things that folks do want to prevent or detect. > Is the mechanism for "protecting" against this attack vector in DKIM anything > like the mechanisms used in those other, similar technologies? In other > words, > if other experts have worked on this, have they solved in a similar way? Sort-of. I think DKIM differs in this in that our default key management is less secure, but were DNSSEC to happen, then I think that inclusion of the k= & h= fields in key records wouldn't be that conceptually different from how TLS handles ciphersuite negotiation. > If the above 3 questions do not have a clear "yes" answer, then we ought to > treat DKIM's effort on this topic as highly suspect. I don't think 4871 is highly-suspect in this (or actually any) respect. > Anything other than 3 yes' means that we're attempted to solve a problem that > other experts do not see as a problem, or that they have not tried to solve > before or that they have solved in a different way. In other words, to some > potentially high degree, we are hanging out entirely on our own. > > My own sense of security work by a crew of folk that have some security > expertise, but is not dominated by it, is that it should aggressively avoid > being creative... Totally agree there. S. > > d/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
