Re: [TLS] Simple, secure 0-RTT for the masses

Ilari Liusvaara <> Wed, 16 March 2016 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CC5112D7D3 for <>; Wed, 16 Mar 2016 01:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQJbYrSKuCn4 for <>; Wed, 16 Mar 2016 01:17:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75AA212D7D4 for <>; Wed, 16 Mar 2016 01:17:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77D6A3116; Wed, 16 Mar 2016 10:17:19 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id 2ZI7IFBWhE6K; Wed, 16 Mar 2016 10:17:19 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3342821C; Wed, 16 Mar 2016 10:17:19 +0200 (EET)
Date: Wed, 16 Mar 2016 10:17:17 +0200
From: Ilari Liusvaara <>
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Mar 2016 08:17:34 -0000

On Wed, Mar 16, 2016 at 12:33:40AM -0400, Colm MacCárthaigh wrote:
> On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox <> wrote:
> > I would be happy if we could recommend at least one reasonably secure
> > method for 0-RTT for HTTPS that has a reasonable chance of satisfying the
> > skeptics, and then state that 0-RTT for other protocols, and stateless
> > 0-RTT, needs to be carefully considered for the application.
> >
> After meditating on this a little, how about something like this:
> Benefits Forward secrecy:
> * Clients SHOULD use a resumption ticket only once, and get a new
> resumption ticket when using an existing one.
> Benefits Forward Secrecy and Idempotence:
> * Client and server should erase the existing ticket upon use.
> (a captured early data section is mooted for replay quite quickly in the
> default "good" case)

The best that can be done w.r.t. "forward secrecy" is to erase the
decryption-capable key used for 0-RTT on both sides, and never sending
it on the wire, even encrypted.

> * Make early data and application data separate record layer content types.
> Make it clear that they do not form a continuous stream; you can't simply
> concatenate them at the application level and bolt on to existing protocols
> such as HTTP, SMTP, etc.

You mean inner (encrypted) content type, right (outer content type would
still be 23[TLS PROTECTED DATA]?

> * Advise that clients using 0RTT SHOULD occasionally send duplicate early
> data handshakes. As a normal part of the protocol, a well behaved client
> should intentionally do what an attacker might do and send the whole
> section twice, causing the server to resolve the duplication. Keep the
> anti-bodies strong.

Such duplication does not occur in attack conditions. The duplication
from attack conditions takes two forms:

- Duplication of 0-RTT data into 1-RTT data of _different_ connection.
- Duplication of 0-RTT data into 0-RTT data of _different_ connection.

In both cases, the connections are different, not the same. And this
makes a difference if e.g. protocol banners are sent as 0-RTT (and
such may very well be critical for latency).