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

Brian Smith <> Tue, 23 February 2010 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2403C3A74BE for <>; Tue, 23 Feb 2010 08:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.358
X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqS3RtM10izV for <>; Tue, 23 Feb 2010 08:50:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D210F28C13A for <>; Tue, 23 Feb 2010 08:50:49 -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 92721509B4; Tue, 23 Feb 2010 11:52:43 -0500 (EST)
Message-ID: <>
Date: Tue, 23 Feb 2010 10:52:39 -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="------------000604050002020507010307"
Cc: Simon Josefsson <>,,
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: Tue, 23 Feb 2010 16:50:51 -0000

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. 

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