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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Thu, 18 February 2010 18:59 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 CC5EF3A8026 for <tls@core3.amsl.com>; Thu, 18 Feb 2010 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 kasCcZzPz9D8 for <tls@core3.amsl.com>; Thu, 18 Feb 2010 10:59:09 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id E07AC3A7D6A for <tls@ietf.org>; Thu, 18 Feb 2010 10:59:08 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Feb 2010 14:00:19 -0500
Message-ID: <201002181900.o1IJ0p1U005839@stingray.missi.ncsc.mil>
In-Reply-To: <4B7D811D.50909@briansmith.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
Thread-Index: AcqwxOLCaYgsSXXQQoeFyBf1PrnyoQAAvfTQ
References: <C7A30236.85DC%stefan@aaa-sec.com> <4B7D811D.50909@briansmith.org>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 18 Feb 2010 19:01:36.0859 (UTC) FILETIME=[CB913AB0:01CAB0CC]
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: Thu, 18 Feb 2010 18:59:09 -0000

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.