I don't always agree with Steve but I think he has made a good case on several occasions against the traditional 'menu choices' approach to crypto algorithms. The mere ability to specify a different algorithm ID is not sufficient to provide an upgrade path. Unless both the sender and receiver know which algorithm to expect the ability to specify different algorithms can result in a situation where the security of the system is the security of the weakest of the algorithms on offer rather than the strongest. The strength of the cryptographic algorithm is only one factor in determining the security of the system, in most cases the least important. We still have no confirmed cases of a criminal exploit based on the known insecurity of 40bit SSL or WEP. MD5 is much more secure than either of them. It is important to understand the difference between the preferred cryptographic algorithm and an acceptable one. At this point there is no hash algorithm that is entirely satisfactory. SHA 256 is the nearest to being acceptable but the design of SHA 256 is based on SHA-1 which has issues. >From a security point of view the weaknesses in the hash algorithms are like finding that the floor in your wood framed house drops 3 inches over a 12ft span. The problem is not the roll to the floor, its what the roll might indicate about what is under the floor (possibly termites). The actual compromise known in MD5, SHA-1 and related algorithms are only of immediate concern to a handful of applications. The criteria we demand of hash algorithms are exceptionally conservative. There are realy two sets of recommendations that are needed for crypto algorithms: 1) Algorithms recommended for use in new applications 2) Algorithms that are acceptable for use in legacy applications without concern And then there are: 3) Algorithms that are acceptable for use in legacy applications after careful analysis of the specif use 4) Algorithms that should be avoided at all costs. For example, RSA 2048 would be in the first category, RSA 1024 and SHA1 in the second, DES and MD5 in the third, RSA 512 would be in the fourth. I think that in general there should only be one or at most two algorithms recommended for a certain type of operation. The performance differences between SHA1 and SHA256 are so marginal that I don't think they should be accepted as cause for allowing an algorithm option. I have in the past been very much opposed to ECC but the current level of backing for ECC and 'SuiteB' crypto from the NSA does come with some powerful arguments. There is certainly a sharp drop off in performance of RSA above 2048 bits. There are IPR issues but these may well solve themselves within an acceptable time frame (no patent lasts forever). Phill > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Steven M. Bellovin > Sent: Monday, November 28, 2005 11:49 AM > To: Ted Lemon > Cc: iesg@xxxxxxxx; dhcwg@xxxxxxxx; namedroppers@xxxxxxxxxxxx; > Pekka Savola; ietf@xxxxxxxx > Subject: Re: DHCID and the use of MD5 [Re: Last Call: > 'Resolution of FQDNConflicts among DHCP Clients' to Proposed > Standard] > > In message <200511261243.21694.mellon@xxxxxxxxx>, Ted Lemon writes: > >Making a hash function interchangeable in DHCID makes the > conflict detection > >algorithm hugely more complicated, and possibly not workable > at all. Think > >about how that would work. > > > I confess that I don't see the problem. The updater would do > a DNS query for DHCID RRs; it would be given all of the > stored records. The updater would then use local policy -- > that is, an ordered list of preferred hash functions -- until > it found one that was in the response. That one would be > used. If no locally-known hash functions are in the list, it > should behave as if there were no DHCID records present for > that name. DNSSEC could protect against downgrade attacks. > (Speaking of which -- were I still AD, I'd ding this document > for an inadequate Security Considerations section -- apart > from the lack of discussion of brute force attacks, you > should cite 3833 for DNS attacks and explain what the risks > are if someone can crack the hash function by any means, > including brute force or eavesdropping on the wire or > (perhaps) a misbehaving updater.) > > If you don't agree, I'd strongly suggest using SHA-256 > instead of MD5. > Yes, it's more expensive, but I doubt that that's a major hit > on overall system performance here. It would also be useful > to include in the document some discussion of upgrade > strategy -- how would we ever switch to a new hash function? > That's non-trivial even for protocols designed for agility, > as Eric Rescorla and I have shown. No matter how it's done, > this one is among the very hardest, since DNS servers would > have to supply DHCID records for several hashes for a number of years. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf