Re: [TLS] Single round trip abbreviated handshake

Adam Langley <agl@google.com> Wed, 03 February 2010 11:40 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 A0C0E3A6C28 for <tls@core3.amsl.com>; Wed, 3 Feb 2010 03:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.477
X-Spam-Level:
X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 DV8gGavhOr8s for <tls@core3.amsl.com>; Wed, 3 Feb 2010 03:40:01 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B9C413A6C2B for <tls@ietf.org>; Wed, 3 Feb 2010 03:40:00 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o13Beewi007173 for <tls@ietf.org>; Wed, 3 Feb 2010 11:40:41 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265197241; bh=tjCtNgrCrre5y5xuH/gVEDEfOh0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dln4dqjpZvSPVskXovuD4qMyCvaYldhSH0+wHQbW1B8GltaHAVMwFBvemCIpQ6ZZU zbLxoOVz3q+exa4pq0T9g==
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=qGihKrOe+q2vuWR1tjjKnMninFRj7l+BjZhV907ipLraVGehlq0chmnBE3FmxtiOT wursR0RT80cHJmX9drZqQ==
Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by wpaz13.hot.corp.google.com with ESMTP id o13BeJTc031478 for <tls@ietf.org>; Wed, 3 Feb 2010 03:40:39 -0800
Received: by pxi8 with SMTP id 8so1175284pxi.19 for <tls@ietf.org>; Wed, 03 Feb 2010 03:40:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.119.9 with SMTP id r9mr1419492wfc.201.1265197238321; Wed, 03 Feb 2010 03:40:38 -0800 (PST)
In-Reply-To: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com>
References: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com>
Date: Wed, 3 Feb 2010 06:40:38 -0500
Message-ID: <a84d7bc61002030340l43de0f6cw2b92b5ab39d82b7f@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Ravi Ganesan <ravi@findravi.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] Single round trip abbreviated handshake
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: Wed, 03 Feb 2010 11:40:02 -0000

On Tue, Feb 2, 2010 at 11:12 PM, Ravi Ganesan <ravi@findravi.com>; wrote:
> Adam/Google was going down this road independently. Adam has suggested
> server-random = function(client-random, unix-gmt, epoch) where last
> value is derived from Server cert.

At the moment, OCSP disk caches and OCSP stapling are the low hanging
latency fruit, but this idea has been knocked around at Google.

However, I didn't explain the 'epoch' bit very well in my emails to
Ravi so I'll try again.

The goal is to give the server an nonce. If the server chooses a long
random string then the job is obviously done. However, if the server
promises to only accept each nonce once, for all time, then we have an
nonce via another route. In order for the server to do this it needs
to bound its storage. Loose clock synchronisation gets us that. The
server can make a trade off between how loose and how much storage.

The epoch value was intended to be learnt by the client (since the
clients need to know the server's certificate before hand anyway) and
used to segment the nonce space. Consider two different clusters on
different sides of the world, both using the same certificate. Without
an epoch value (which would be specific to each cluster) they would
have to synchronise with each other for every new nonce.

Also, it's very expensive to provide durable transactions for
frequently changing data. If we kept the "used nonce" store in memory
then we would need a way to invalidate all previous nonces in the
event of a power failure or other data loss. Changing the epoch value
would suffice here.

However, having the server's nonce be non-fresh leads to this attack:

Client (A) performs a 0-RTT setup to a server (B). This means that it
sends (somehow) enough information for a valid server to extract
application data with no additional round trips. An attacker (M)
intercepts A's traffic and stops it. A sees a timeout as B never
replies. However, the nonce was never used, so M can replay A's
message at a later time.

This suggests that 0-RTT techniques could only be used when the
request is side-effect free (as GETs are supposed to be in HTTP).

That rather scary and we shant be rushing into anything here.


AGL