[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Yet another SHA/MD5 comment .... my last



 
>I strongly oppose any efforts to completely scrap HMAC-MD5 because .... 
 
It would seem easier to use SHA for all baseline specification under 
consideration, not because HMAC-MD5 has a specific vulnerability, but because 
we want to limit the number of choices.  So, to clarify my earlier comments to 
this poll ... HMAC-SHA should be mandatory for AH and anything else should be 
elective.  
 
Protocol      Mandatory Transform 
---------------------------------- 
AH            HMAC-SHA 
ESP           SHA-DES  (tbd - SHA inside or outside ...  DES-SHA) 
 
 
 
Paul 
 
 
 
 
-------------------------------------------------------------- 
Paul Lambert                     Director of Security Products 
Oracle Corporation                       Phone: (415) 506-0370 
500 Oracle Parkway, Box 659410             Fax: (415) 413-2963 
Redwood Shores, CA  94065               palamber@us.oracle.com 
-------------------------------------------------------------- 
  


-- BEGIN included message


In message <31A4E010.3BA9@cylink.com>, you write:
>My position is that MD5 should be immediately abandoned for use in ANY mode.  
>MD5 is a cryptographic algorithm the strength 
>of which is serious dispute.  It should be removed from consideration by IETF 
>and other standards committee for use in any 
>form.

	Then I trust you'd be happy to do a quick demonstration and hijack
an AH HMAC-MD5 protected TCP connection?

	Until you can show me that, I believe that MD5 has value. The value is
that random people cannot defeat it. Maybe major governments can. When it comes
to MY traffic, *I* want to be able to make the trade-off between security and
performance.

	I strongly oppose any efforts to completely scrap HMAC-MD5 because
it's taking away a legitimate and reasonable choice for the end user.

>I also think that implementors should re-examine the cost to move to SH
>A-1 versus the cost of retaining a hash 
>function that probably has a limited lifetime.

	The flaw in this line of thinking should be obvious.

								-Craig

-- END included message