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

Stefan Santesson <stefan@aaa-sec.com> Wed, 24 February 2010 16:59 UTC

Return-Path: <stefan@aaa-sec.com>
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 1C7EE28C1D8 for <tls@core3.amsl.com>; Wed, 24 Feb 2010 08:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level:
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 OO66Zw7z6-zS for <tls@core3.amsl.com>; Wed, 24 Feb 2010 08:59:01 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id F0D8D28C15C for <tls@ietf.org>; Wed, 24 Feb 2010 08:59:00 -0800 (PST)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id EB8E9339469 for <tls@ietf.org>; Wed, 24 Feb 2010 18:01:11 +0100 (CET)
Received: (qmail 72091 invoked from network); 24 Feb 2010 17:01:00 -0000
Received: from unknown (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 24 Feb 2010 17:01:00 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 24 Feb 2010 18:00:47 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, <mrex@sap.com>
Message-ID: <C7AB19CF.88B9%stefan@aaa-sec.com>
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Thread-Index: Acq1cujLRXODTj3ZEkS0IhmoriFNkA==
In-Reply-To: <4B8407D7.9040207@briansmith.org>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349879260_4790908"
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: Wed, 24 Feb 2010 16:59:03 -0000

Would it help to make everyone happy if we said that implementers SHOULD
support SHA-1?

/Stefan



On 10-02-23 5:52 PM, "Brian Smith" <brian@briansmith.org>; wrote:

> 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
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls