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