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

[Martin Rex <[e-mail]>]

Simon Josefsson wrote:
> 
> Brian Smith <[e-mail]> writes:
> 
> > 1. As long as this web page on the NIST website says, basically,
> > "don't use SHA-1 for anything," people will want to disable SHA-1
> > whenever they can. It doesn't matter that this page on the website
> > isn't the official NIST recommendation on the matter.
> 
> 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.

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.

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

> 
> 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)?


-Martin