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

Adam Langley <agl@google.com> Tue, 02 February 2010 13:44 UTC

Return-Path: <agl@google.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 33B1028C0F2 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 05:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 zbXJG+sLSSyu for <tls@core3.amsl.com>; Tue, 2 Feb 2010 05:44:54 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 56FE528C132 for <tls@ietf.org>; Tue, 2 Feb 2010 05:44:54 -0800 (PST)
Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o12DjVGh008751 for <tls@ietf.org>; Tue, 2 Feb 2010 05:45:31 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265118332; bh=PKqCjB33nf6Kpyta2IuP6CBDNpQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ujbbhXmF019KyqegOTbZ63jv2QSWb4DPXzpW7k+BZVmYPs9UV5eZ1P2DNeWKXguzU 2THE09j14aATRCY60hKuw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=GKLXZmhUKXBVrMAfq+raUGMpScWeWO1B7VlYdXkVxIbhMzeXii43+fRKRHYabp6Dw Sq0Z37Xiqsy294KWTUpVA==
Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by kpbe15.cbf.corp.google.com with ESMTP id o12DiwPB008784 for <tls@ietf.org>; Tue, 2 Feb 2010 05:45:30 -0800
Received: by pzk30 with SMTP id 30so63188pzk.11 for <tls@ietf.org>; Tue, 02 Feb 2010 05:45:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.119.9 with SMTP id r9mr489708wfc.201.1265118330531; Tue, 02 Feb 2010 05:45:30 -0800 (PST)
In-Reply-To: <001901caa3e4$c0363750$40a2a5f0$@org>
References: <001901caa3e4$c0363750$40a2a5f0$@org>
Date: Tue, 2 Feb 2010 08:45:30 -0500
Message-ID: <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
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: Tue, 02 Feb 2010 13:44:55 -0000

On Tue, Feb 2, 2010 at 3:50 AM, Brian Smith <brian@briansmith.org>; wrote:
> I am very interested in the ideas that motivate the cached info extension.
> It obviously makes sense for the client to tell the server that it already
> knows the certificate, so that the server doesn't have to send the
> certificate.

Indeed. I've been bugging the author of this draft to update it
somewhat(*) and repost here. I've also written implementations for
OpenSSL and NSS. Hopefully life can be injected into this draft.

(* Martin Rex requested that the server inform the client of the
degree of its support for cached-info, to save the clients uselessly
caching information. This seems like a good idea)

> But, if the client already knows the certificate, then it
> already knows the server's public key. Consequently, it is wasteful for the
> client NOT to send the ClientKeyExchange along with the client hello.

Given a client-speaks-first protocol like HTTP (which I happen to be
mostly concerned with), this could cut the full handshake from two to
one round trips.

However, there's a much easier way of doing this: cut through mode. In
this scheme the client starts sending application data records without
waiting for the server's Finished message so long as the ciphersuite
is sufficiently strong. Android already does this.

However, with cached certificates it's possible to get a full
handshake down to 0-RTT if the client can choose the server's random.
This means that the server has to be able to assert that it will never
reuse the same random, but that's doable if you assume some degree of
clock synchronisation and client-cached epoch values.

This idea has been banging about for a while now and you're the second
person that I've seen mention something similar in a week. I intend to
start experimenting with this, hopefully this quarter.


AGL