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

Brian Smith <brian@briansmith.org> Thu, 18 February 2010 18:02 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 D71BC28C2F2 for <tls@core3.amsl.com>; Thu, 18 Feb 2010 10:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 dWiGXk5bokEt for <tls@core3.amsl.com>; Thu, 18 Feb 2010 10:02:38 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id D334428C2FA for <tls@ietf.org>; Thu, 18 Feb 2010 10:02:37 -0800 (PST)
Received: from [192.168.1.65] (unknown [70.253.63.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4605D22E25B; Thu, 18 Feb 2010 13:04:14 -0500 (EST)
Message-ID: <4B7D811D.50909@briansmith.org>
Date: Thu, 18 Feb 2010 12:04:13 -0600
From: Brian Smith <brian@briansmith.org>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>, tls@ietf.org
References: <C7A30236.85DC%stefan@aaa-sec.com>
In-Reply-To: <C7A30236.85DC%stefan@aaa-sec.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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: Thu, 18 Feb 2010 18:02:38 -0000

Stefan Santesson wrote:
> Well,
>
> I went through my change list and have now updated and reposted the draft as
> draft-03.
>
> Changes can be viewed from:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-03.txt
>    
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.

The client already has to calculate hashes of each certificate in the 
certificate chain, using algorithms fixed at the time each certificate 
was signed. The client and server implicitly trust all of these 
algorithms if they accept the certificate chains. X.509 libraries 
already provide efficient access to these hashes. Also, given the 
fingerprint of the sender's certificate, you can determine the entire 
certificate chain if all the certificates are available in the cache. 
Consequently, it would be much better if hash used for identifying a 
cached certificate was the same as the fingerprint of the sender's 
certificate, instead of a hash of the entire certificate chain using one 
or more other algorithms.

The server already told the client what hash algorithms it supports in 
CertificateRequest message from which the client extracted the cached 
certificate_authorities. The client can just pick *one* of those 
algorithms when hashing the certificate_authorities--most likely, the 
hash algorithm used by for the signature of its own certificate. I don't 
see why it's valuable for the client to be able to include multiple 
hashes in its ClientHello. In other words, I think CachedInformation 
should be removed and all uses of it replaced by CachedObject.

But, then you can go even farther and remove CachedObject and 
CachedInformationType:

enum { cached_certificate_chain(TBD), cached_trusted_cas(TBD), (65535) } 
ExtensionType;

The "extension_data" field of each of these extensions, when included in 
the client hello, SHALL contain CachedInformationHash according to the 
following structure:

struct {
     HashAlgorithm hash;
     opaque hash_value<1..255>;
} CachedInformationHash;

Then the server could indicate which items it supports by including 
empty extension(s) with the corresponding type(s), which is what most 
other extensions do.

Regards,
Brian