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

Stefan Santesson <stefan@aaa-sec.com> Fri, 19 February 2010 08:42 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 5B6B428C1F1 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 00:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 Ffo9-HxwDBcf for <tls@core3.amsl.com>; Fri, 19 Feb 2010 00:42:28 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 7C2C028C1FB for <tls@ietf.org>; Fri, 19 Feb 2010 00:42:27 -0800 (PST)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6AFA4348649 for <tls@ietf.org>; Fri, 19 Feb 2010 09:38:40 +0100 (CET)
Received: (qmail 31349 invoked from network); 19 Feb 2010 08:38:37 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <DPKemp@missi.ncsc.mil>; 19 Feb 2010 08:38:37 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 19 Feb 2010 09:38:36 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>, <tls@ietf.org>
Message-ID: <C7A40C9C.8640%stefan@aaa-sec.com>
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
Thread-Index: AcqwxOLCaYgsSXXQQoeFyBf1PrnyoQAAvfTQAB3Eqy0=
In-Reply-To: <201002181900.o1IJ0p1U005839@stingray.missi.ncsc.mil>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
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: Fri, 19 Feb 2010 08:42:29 -0000

+1 on Dave's comment here.

Note that SHA1 is "MUST support". It is not "MUST use".
You don't have to send a SHA1 hash, but if you do, you can be confident that
the recipient can handle it.

/Stefan


On 10-02-18 8:00 PM, "Kemp, David P." <DPKemp@missi.ncsc.mil>; wrote:

> The security considerations section already points out that collision
> avoidance is not a requirement:
> 
>    Failure of a provided hash to correctly and uniquely
>    identify the correct set of hashed parameters may at most lead to a
>    failed TLS handshake followed by a new attempt without the cached
>    information extension. No serious security threat requires selected
>    hash algorithms to have strong collision resistance.
> 
> CRC32 would provide sufficient uniqueness for this application, but
> since client libraries already include SHA-1, it is a convenient (albeit
> slower and overqualified) substitute.  The interoperability benefit of
> requiring support for a common algorithm:
> 
>    Compliant implementations MUST support "wxyz" as HashAlgorithm.
> 
> ... far outweighs any conceivable benefit of not requiring support for a
> common algorithm.   Algorithm agility, negotiation, and version
> dependencies would be grotesque complexities in this context.
> 
> Dave
> 
> 
> 
> -----Original Message-----
> From: Brian Smith
> 
> 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls