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

Brian Smith <> Fri, 19 February 2010 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 047503A7B3A for <>; Fri, 19 Feb 2010 07:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R9Rdm-pVRSwi for <>; Fri, 19 Feb 2010 07:04:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 339E53A6A3D for <>; Fri, 19 Feb 2010 07:04:36 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C9F2222E254; Fri, 19 Feb 2010 10:06:15 -0500 (EST)
Message-ID: <>
Date: Fri, 19 Feb 2010 09:06:15 -0600
From: Brian Smith <>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080608070103070606070503"
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Feb 2010 15:04:38 -0000

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.

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