At 11:15 AM -0500 11/29/05, Sam Hartman wrote:
First, I brought up random oracle in an aside to Steve Bellovin. I'm
not sure it particularly matters to this case.
It doesn't seem like an "aside", it seems central to the objection to
the use of MD5.
So, I know of nothing that asks little of a hash and can be used for
privacy. The only model I know that can be used for privacy is random
oracle and that asks a lot of a hash.
Every protocol that uses a hash for privacy does so knowing that
using the hash instead of the cleartext cause the attacker to have to
do some number of hash attempts in order to detect the contents. From
the cryptographic literature I have seen, random oracle strength of a
hash is close to the length of the hash. I certainly could have
missed something, and there may be new thinking based on the
collision-resistance weakening of MD5 and SHA-1. If so, there should
be a clear explanation from the Security Area of how protocols can
and cannot use hashes for privacy.
It seems absurd to be having this discussion the the general IETF
list instead of on the CFRG.
1) algorithm agility.
There are two kinds of algorithm agility:
- build it into the protocol
- rev the protocol each time you want to use a new algorithm
Everyone always has the second. The protocol developer already made a
strong argument against the first, namely that the protocol as
described is already in wide deployment. Thus, the two kinds have
pretty much the same effect on implementers of DHCID.
2) Remove paragraph about existing md5 attacks not being an issue or
come up with theoretical justification for that paragraph.
A better solution would be to follow Steve Bellovin's suggestion to
beef up the Security Considerations to detail what is being
protected. The fact that the material being obscured is already being
moved around the network in the clear is quite relevant to the attack
scenarios.
3) Use sha-1 or sha-256 instead of md5.
This seems completely arbitrary, given that we do not know how much
strength of privacy is needed. It is also arbitrary until someone can
say how much strength each algorithm gives the protocol, and that has
yet to be stated.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf