Folks,
Much as its nice to see technical discussion on this list, the RR
is last on our list of things to do, whereas the threat analysis is
first, and will be a blocking factor later on, so can we try to
amass a list of threats that aren't covered in the latest draft
as a priority?
There's one below to get us going, dunno if folks like this
format, but I guess Jim'll tell us what he wants.
Regards,
Stephen.
Threat: hash-collisions-from-originator
Description: If DKIM uses a hash function which is vulnerable
to collision finding and if the to-be-signed data is
suffficiently predictable, then an attacker could potentially
find some colliding values, then embed those into a message
which it submits to the signing MTA such that (parts of) the
signed message can be replaced with a message based on the
colliding value.
Impact: Decreases confidence in DKIM signatures generally;
potentially allows damaging mail through filters if DKIM-signed
mail is checked less.
Countermeasure: Use a strong hash function (to the extent
possible), probably sha256 today. Plan to be begin planning
to migrate in the next year/two once consensus emerges in
the crypto community as to how to embed signer-generated
randomness into hashing.
Probability of occurrence: With the above countermeasure this
is low probabillity; if sha-1 support is maintained then this
should be considered medium/high; if md5 support is at all
possible then would become high probability.
Note: If commensurate-strength cryptography were a requirement
for DKIM then we should move to 3072 bit RSA keys when using
sha256. However, I think we can defend a combination of
rsa1024 with sha256 here since 80-bit collision resistance is
ok for us for now. (Must check that with crypto folks at
some stage.)
_______________________________________________
ietf-dkim mailing list
http://dkim.org