Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

["Kemp, David P." <[e-mail]>]

I'd be happier with MUST.  I don't buy the argument that all code that
makes up an application must come from a certified crypto library;
certainly XML parsers, GUI toolkits, and a million other things are
available to developers, and I find it hard to believe that 20 years
from now nobody will be able to find some C code somewhere to do SHA-1.
If it is impossible to get consensus without a SHOULD, then so be it,
but that is a cop-out.

 

I agree with Martin and Brian that all hashes including SHA-1 should be
truncated.  To make it impossible for developers to miss (and to save a
few bits of bandwidth) it should be truncated to less than 20 octets.
I'd suggest 8 octets, but pick your favorite number (8, 12, 16) less
than 20.

 

      struct {

           HashAlgorithm hash;

           opaque hash_value<8>;      // was hash_value<1..255>;

      } CachedInformationHash;

 

Dave

 

 

From: Stefan Santesson [mailto:[e-mail]] 
Sent: Wednesday, February 24, 2010 12:01 PM
To: Brian Smith; [e-mail]
Cc: Simon Josefsson; Kemp, David P.; [e-mail]
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track"
draft

 


Would it help to make everyone happy if we said that implementers SHOULD
support SHA-1?

/Stefan



On 10-02-23 5:52 PM, "Brian Smith" <[e-mail]> wrote:

Martin Rex wrote: 


Simon Josefsson wrote:
  
 


 
I'd like to suggest another argument to support your reasoning: some
FIPS approved crypto libraries no longer export MD5.  I expect the same
to be true for SHA-1 within a few years.  This means that SHA-1 will no
longer be as easily available, for these non-crypto purposes needed in
tls-cached-info.
    
 



I do not agree to this conclusion.  IIRC, NIST never liked MD5 from
the beginning, and it was always clear about that, which is why
SHA-1 as an alternative became ubiquitous available everywhere where
a secure hash algorithm was needed.
  

In the short term, Martin is right. Even with the new recommendations,
crypto modules will still be able to be FIPS-certified even if they
contain a SHA-1 implementation, as long because SHA-1 still has approved
uses (HMAC-SHA1 in particular). However, I'm not sure that will be the
case 10 years from now. I think it would be better for this extension to
be specified in a way that doesn't require it to be periodically updated
in order to be implementable using only primitives provided by certified
crypto modules.


While it seems sensible to deprecate SHA-1 for use in digital
signatures, it is still present in many certs and many signatures.
Even last year, some PKIs have been newly set up with a hierarchy
of CAs using SHA-1 for the signature on the intermediate CA and
end entity certs--probably because the SHA-2 algorithm is not
yet universally available in implementations.
  

It depends on the application. In 2011, SHA-1 certificates will no
longer be acceptable for many uses within the US government. And, that
is already the case now in 2010 with the German government, AFAICT.


If you look at the mandatory-to-implement algorithm for SSLv3 and
TLS up to v1.2 (rfc5246):

  TLSv1.0 (rfc-2246, section 9)  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  TLSv1.1 (rfc-4346, section 9)  TLS_RSA_WITH_3DES_EDE_CBC_SHA
  TLSv1.2 (rfc-5246, section 9)  TLS_RSA_WITH_AES_128_CBC_SHA
  
So getting rid of SHA-1 will require a significantly larger effort
than getting rid of MD5 (-based signatures).
  

The spec says that those algorithms are required unless the profile of
TLS in use specifies otherwise. The NSA Suite B Profile for TLS (RFC
5430) defines a profile that doesn't use SHA-1 at all.
(http://tools.ietf.org/html/rfc5430#section-3). 

 


Chosing SHA-256 will give us more time, but we'll likely run into the
same issue eventually anyway.  I believe this suggests that algorithm
agility is useful whenever any crypto-related algorithm is _used_, even
if it is used for non-crypto related purposes.
    
 


TLS truncates the PRF output to 12 octets for the finished message.
Maybe we should truncate the hash for the caching extension to
20 octets (which means that sha-1 hash values are sent in full)?
  

That sounds reasonable to me, but I'd also require the SHA-1 hashes
truncated too, because (a) SHA-1 is overkill too (as David Kemp pointed
out), and (b) it would be impossible for an implementer to miss the
truncation requirement, evein in a SHA-1-only implementation.

Regards,
Brian

  _____  

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls