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

Brian Smith <brian@briansmith.org> Thu, 25 February 2010 16:54 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 763B528C37B for <tls@core3.amsl.com>; Thu, 25 Feb 2010 08:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level:
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 f9eC67RMGFlt for <tls@core3.amsl.com>; Thu, 25 Feb 2010 08:54:06 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 6D0E628C3D9 for <tls@ietf.org>; Thu, 25 Feb 2010 08:54:06 -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 E125B509E1; Thu, 25 Feb 2010 11:56:08 -0500 (EST)
Message-ID: <4B86ABA7.50201@briansmith.org>
Date: Thu, 25 Feb 2010 10:56:07 -0600
From: Brian Smith <brian@briansmith.org>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <848CABEF-60CE-4CCD-A65C-EA5BB4DB4087@checkpoint.com> <C7AC395B.892B%stefan@aaa-sec.com> <87tyt5cr0b.fsf@mocca.josefsson.org>
In-Reply-To: <87tyt5cr0b.fsf@mocca.josefsson.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <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: Thu, 25 Feb 2010 16:54:07 -0000

Simon Josefsson wrote:
>
> Here is a proposal: Say SHA-1 is a MUST when TLS<  1.2 is negotiated but
> later TLS versions MUST use the same hash as the one used by the PRF?
>
>    
This is what I was originally going to suggest. The problem is that the 
client doesn't necessarily know which PRF will be used until it receives 
the ServerHello because the server could be TLS 1.0/1.1-only, because 
the PRF depends on the ciphersuite chosen by the server, and because the 
PRF for the chosen ciphersuite might not be based on a HMAC.

My first suggestion, a long time ago, was to just use the fingerprint of 
the end certificate as the key for certificate caching. This is 
something that both sides already have to calculate anyway. In fact, 
many implementations are already using the certificate fingerprint as a 
cache key for internal purposes. Then, have the client and server use 
the Client Certificate URL extension if they want to optimize the client 
certificate part, which potentially saves many many more bytes than the 
caching CertificateRequest.certificate_authorities would. Just give up 
defining a generic mechanism; the level of generality and complexity in 
the current draft is really unwarranted.

My second suggestion is to have the server calculate the hash, and give 
the calculated hash to the client along with the content. Then the 
client and the server don't have to agree on any algorithms at all, and 
the server can choose whatever algorithm it wants. If you leave the hash 
identifier in there then the client could potentially double-check the 
server's calculation--something which I think is wasteful, but I think 
it is wasteful to require both sides to calculate the hashes too, 
especially given the extra client-side complexity that it causes.

Regards,
Brian