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

[Brian Smith <[e-mail]>]

Martin Rex wrote:
> Brian Smith wrote:
>    
>>
>> I think it is especially important to have the SHA-1 requirement
>> changed. It is a big hassle to require SHA-1 for compliance when now
>> every use of SHA-1 has to be reviewed. Also, mandating SHA-1 would be in
>> conflict with other requirements--especially requirements to follow NIST
>> and NSA recommendations regarding algorithms. At a minimum, make SHA-1
>> support mandatory only if/when the connection's negotiated version is
>> less than TLS 1.2.
>>      
> I assumed that NIST deprecated the use of SHA-1 only for digital signatures.
>    
 From http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html:

"Regardless of use, NIST encourages application and protocol designers 
to use the SHA-2 family of hash functions for all new applications and 
protocols. After 2010, Federal agencies may use SHA-1 only for the 
following applications: hash-based message authentication codes (HMACs); 
key derivation functions (KDFs); and random number generators (RNGs). "

Notice in particular that NIST has a whitelist of approved uses for 
SHA-1, not a blacklist.
> Implementations of TLS v1.0 and v1.1 may not support anything besides
> SHA-1 within TLS yet.
>    
This reasoning is backwards. A TLS 1.2 implementation doesn't need to 
implement SHA-1 at all, except for backward compatibility. A TLS 1.0/1.1 
implementation would need to be updated to support this extension 
anyway, and the addition of new hash algorithms can be done at the same 
time. Plus, TLS 1.0/1.1 implementations need to be upgraded to TLS 1.2 
anyway, specifically to avoid SHA-1 and MD5.

I already have TLS 1.2 software that contains only NSA Suite B 
algorithms, and that already follows the NIST recommendation to use 
SHA-2 for "all new applications." To implement this specification, I 
would have to add a non-suite-B algorithm to my software. While that is 
a minor technological problem (more code, more testing, more 
documentation), it is a bigger social problem, because it requires 
careful explanation to users/customers that SHA-1 is used, but it isn't 
used in a way that affects the security of the protocol. It is much 
easier to explain to customers that the software doesn't contain 
non-suite-B algorithms at all.
> The use of SHA-1 is not as security critical as you might think it is.
> The _real_ data, identified by the hash, must still be processed, but
> it is taken from the clients cache instead of being transferred
> over the wire.
>    
Yes, I understand this and agree with it. But, it is still in conflict 
with NIST's recommendation, regardless.
>> The server already told the client what hash algorithms it supports in
>> CertificateRequest message from which the client extracted the cached
>> certificate_authorities.
>>      
> That is one of the non-obvious changes in TLS v1.2.
> Prior versions (TLSv1.1,TLSv1.0,SSLv3) do not have a signature
> algorithms element in the CertificateRequest message.
>    
That can be solved by simply hard-coding a hash algorithm for the TLS 
1.0 and TLS 1.1 implementations.

Regards,
Brian