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

> Date: Wed, 08 May 1996 18:16:17 -0700
> From: Tom Weinstein <tomw@netscape.com>

> I strongly oppose splitting the cipher suite up into several seperate
> "fields".  It provides no extra level of flexibility or security and it
> only encourages people to mix and match algorithms in untested ways.
> As I already stated, I believe that allowing negotiation of the algorithm
> used for computing the handshake hashes allows a roll-back attack.  The
> use of a single algorithm is also weaker than the paired algorithms
> currently used.

I agree with Mr. Yee's point that both approaches (fixed single method with
diverse algorithms, and multiple negotiated single-algorithm options)
have merit.  But I believe that the split cipher suite method has more
merit.

This discussion isn't about splitting it into several separate fields,
it's about splitting it into two fields - MAC and everything else.
Despite repeated warnings about untested mixing and matching, I can't
see how switching between multiple hash functions in the MAC computation
can have any hidden effect on the security of the bulk cipher or key
exchange or certificate management.  (There is of course the obvious
effect - Bellovin has shown that encryption without integrity is weak).
If there are any ideas about how switching between two equally-strong
MAC algorithms (say SHA and RIPEMD-160) could affect the security of
the rest of the cipher suite, I'd like to hear them.

There is no reason why the two approaches couldn't be combined - some
of the split-cipher-suite MAC options could be algorithm combinations,
including MD5+SHA.  It would be nice to avoid combinatorial explosion
here, but a few useful combinations could be chosen.

Mr. Dobbertin and Mr. Krawczyk believe that there is still some life
left in MD5 as long as it's used in a HMAC-type nested structure.
This vindicates the merits of using this type of MAC structure, and
should put to rest any thoughts of using a simpler structure to make
precomputation easier.


> Date: Thu, 09 May 1996 00:29:07 -0700
> From: Tom Weinstein <tomw@netscape.com>
> > 
> > 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.

There are at least three ways to address algorithm roll-back attacks:

1) rely on user configuration to disable newly-found-to-be-insecure
   options, then remove the option in the next product release.  This
   sacrifices backward compatibility.

2) address it as version rollbacks are currently addressed in SSL V3
   - maintain compatibility with downrev peers but make it impossible
   for two current peers to negotiate a downrev insecure algorithm.

3) allow user configuration but provide no mechanism to prevent two
   current peers from negotiating downrev options.  Hopefully
   <name-of-tls-protocol> will not go this route.

Received on Thursday, 9 May 1996 09:38:31 UTC