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

Simon Josefsson <simon@josefsson.org> Fri, 26 February 2010 09:36 UTC

Return-Path: <simon@josefsson.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 4FF5F3A86B3 for <tls@core3.amsl.com>; Fri, 26 Feb 2010 01:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 YJwZXD5fzFwH for <tls@core3.amsl.com>; Fri, 26 Feb 2010 01:36:10 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 1A1E93A8682 for <tls@ietf.org>; Fri, 26 Feb 2010 01:36:09 -0800 (PST)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o1Q9cFLv022110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Feb 2010 10:38:17 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Brian Smith <brian@briansmith.org>
References: <848CABEF-60CE-4CCD-A65C-EA5BB4DB4087@checkpoint.com> <C7AC395B.892B%stefan@aaa-sec.com> <87tyt5cr0b.fsf@mocca.josefsson.org> <4B86ABA7.50201@briansmith.org>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100226:brian@briansmith.org::7kIp7CwzRWC90vjS:0AB/
X-Hashcash: 1:22:100226:tls@ietf.org::FIhAAXVhbNt+7qXV:H+rX
Date: Fri, 26 Feb 2010 10:38:16 +0100
In-Reply-To: <4B86ABA7.50201@briansmith.org> (Brian Smith's message of "Thu, 25 Feb 2010 10:56:07 -0600")
Message-ID: <877hq0balz.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Fri, 26 Feb 2010 09:36:11 -0000

Brian Smith <brian@briansmith.org>; writes:

> 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.

Ouch.  Maybe we could do it on the TLS protocol version advertised by
the client then?  We'd get agility, but slower transition since older
versions are still advertised.  Thus, clients still advertising at
minimum TLS v1.0 or v1.1 would MUST support/use SHA-1, clients at
minimum advertising TLS v1.2 would MUST support/use SHA-256.  I'm not
sure what to do say about future versions though.  Can we say "use the
default PRF algorithm"?

> 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.

I don't think the X.509 certificate is a good idea here -- TLS can be
used without X.509 certificates.

> 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.

I like this approach.  The server gets to chose the hash, and the client
will have to comply.  It is easy to implement, and it is possible to
transition to other checksum algorithms over time.

One improvement may be for the client to send a list of hashes it
supports, though, and the server picking the best subset of it, as long
as it is compatible with what it supports?

/Simon