- From: Dan Simon <dansimon@microsoft.com>
- Date: Thu, 9 May 1996 12:07:40 -0700
- To: "'Bennet Yee'" <bsy@cs.ucsd.edu>, "'Tom Weinstein'" <tomw@netscape.com>
- Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
>From: Tom Weinstein[SMTP:tomw@netscape.com] > > >I think there are two different philosophies about how to react to a >failure of one of the MAC functions. The SSL 3.0 philosophy seeks to >design a redundant system that can withstand a single failure but then >requires a patch to regain the redundancy. The STLP strawman >philosophy >allows a failure to compromise the system, but allows it to be fixed by >a simple configuration change on the part of either party. Both >philosophies have merit. If it is believed that SHA is not dependable enough, but that SHA concatenated with MD5 *is*, then a natural solution is to define a new hash function consisting of the concatenation of the two (call it SHAMD5 :^), and include it as an optional hash function for the protocol (perhaps as a separate "handshake/signature authentication hash function" parameter--once again, we see the value of negotiating security parameters independently.....). Implementers and administrators are then free to support SHAMD5--perhaps *only* SHAMD5--as their hash function of choice (for handshake and signature authentication, or even for general use). Alternatively, the protocol could negotiate a "primary" and "secondary" hash function, so that redundant MAC constructions could continue to be redundant into the future (unlike the SSL v3.0 "redundant" construction, which now turns out to be much less redundant than it was originally thought to be). I expect it would be simpler, however, just to define these combined hash functions as they become necessary. (SHARIPEMD, anyone?) And it's certainly less appealing to require what amounts to a significant protocol revision every time an explicitly embedded hash function is broken. > >> A roll-back attack is possible only if the hash function remains >> enabled. Whether a revocation style of cryptographic primitive >> management to automate things is doable or manual, user intervention >> is used, it -is- possible to disable the use of some >> crypto-primitives. Completely disabling a (newly found to be) weak >> crypto-primitive is preferable to leaving it in place. > >Absolutely. But the only way to defeat the roll-back attack is to have >every installed product that uses the insecure algorithm configure it >off. >Personally, I worry that as more and more naive users begin to rely on >cryptographic software, it will become harder for us to do that. Maybe I'm out of touch, but I would expect users to be more likely to toggle a configuration switch to disable a broken hash function than to install a new implementation of the next version of the protocol, whose only change from the previous version is in the pair of hash functions chosen for its "redundant" MAC construction. Daniel Simon Cryptographer, Microsoft Corp. dansimon@microsoft.com > > > >
Received on Thursday, 9 May 1996 15:09:12 UTC