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

Brian Smith <brian@briansmith.org> Tue, 23 February 2010 16:50 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2403C3A74BE for <tls@core3.amsl.com>; Tue, 23 Feb 2010 08:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.358
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqS3RtM10izV for <tls@core3.amsl.com>; Tue, 23 Feb 2010 08:50:50 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id D210F28C13A for <tls@ietf.org>; Tue, 23 Feb 2010 08:50:49 -0800 (PST)
Received: from [192.168.1.65] (unknown [70.252.11.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 92721509B4; Tue, 23 Feb 2010 11:52:43 -0500 (EST)
Message-ID: <4B8407D7.9040207@briansmith.org>
Date: Tue, 23 Feb 2010 10:52:39 -0600
From: Brian Smith <brian@briansmith.org>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: mrex@sap.com
References: <201002221541.o1MFfSBu007590@fs4113.wdf.sap.corp>
In-Reply-To: <201002221541.o1MFfSBu007590@fs4113.wdf.sap.corp>
Content-Type: multipart/alternative; boundary="------------000604050002020507010307"
Cc: Simon Josefsson <simon@josefsson.org>, DPKemp@missi.ncsc.mil, tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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. 
(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