W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

RE: [Fwd: HMAC-MD5: to be or not to be?]

From: Dan Simon <dansimon@microsoft.com>
Date: Thu, 9 May 1996 12:07:40 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960509190740Z-11495@tide21.microsoft.com>
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
>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

>> 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
>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.

Received on Thursday, 9 May 1996 15:09:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC