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

Bill Cox <> Tue, 15 March 2016 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74AE612D9E8 for <>; Tue, 15 Mar 2016 13:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7sWMof6s-wRV for <>; Tue, 15 Mar 2016 13:59:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC64012D784 for <>; Tue, 15 Mar 2016 13:59:52 -0700 (PDT)
Received: by with SMTP id mh10so25931848igb.0 for <>; Tue, 15 Mar 2016 13:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=aubnXyGXITRTHV6LelblEGqPKVxklwbBCAwJfjuD3y4=; b=fWh9MDNM4mR+4II4uZOezjMPVSjKzrE9bZ4M9hoYwDNhawngy5yrTCs/jXWBu4TYGr 6LNj55A2BEJAdyWtUNXCF2+3/kBbNl7JONagalp8PfH/KH5b3wZ6+idmQ/RWAMbnahED snaQCBaEDkl6Ze75ZtyBWgpXa0yvIdTgCalbdSnG0detf13FIQ4dGEnZvF6ahAZP//0G OPg9I2bcAFRMs4ycJC7acQegB8YYDe5J1HtyWq+aADOOqqEjjk4eC1K2aQRcC4E2tf1Z Pf2jglwg5nb/8wl5EGfNQ3PbnKEFLrmttAZ2QLn8NjBtPliCLhldHRzNKaqkkLCT89RN 54wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aubnXyGXITRTHV6LelblEGqPKVxklwbBCAwJfjuD3y4=; b=K8MdoRBeoSNQBCCBIEtyk06VHUrdu/rYmhUiJQBJvHXMMEnqMQQsvMESz1YLxwCQAX 8l5Ac+XrUuG54E1M+eAdcU6bSdebv4kvv25bAmtm90ABeWfigESk6AfG7UXTUyKkm9oN 5Ii2xH1pe12YaBCHGfL7OGrYSUEJk7Snaa6P9H5v/CrHG5ZUMURHyd0MgmHsa+4SVKdM Obh47yGwjdWnZ2NpZx9pIB4myVMS5JGrlr7P7zuOsRfauID7bOOkGisfUPDeqbeYqjo8 0pE6BOLCBi3iVKpHTIWH8q4L+O9keofQhOeyHhLTEOiZh2qmApabclP/gkr6qdbdrwC9 q63w==
X-Gm-Message-State: AD7BkJJbmlSSmzxxZa6BDgPNcymZT3u4O7rxhQfsBCj7HOccB8YawLcs0jMQlqoGMdPdSorFWhUJAL42q28z/3bt
MIME-Version: 1.0
X-Received: by with SMTP id g19mr873634igt.4.1458075591817; Tue, 15 Mar 2016 13:59:51 -0700 (PDT)
Received: by with HTTP; Tue, 15 Mar 2016 13:59:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 15 Mar 2016 13:59:51 -0700
Message-ID: <>
From: Bill Cox <>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Content-Type: multipart/alternative; boundary=047d7bdc15b2b4fa86052e1cad71
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: Tue, 15 Mar 2016 20:59:55 -0000

On Tue, Mar 15, 2016 at 1:21 PM, Colm MacCárthaigh <>

> Here the resumption counts have to be synchronized between the client and
> server, but is the count cryptographically authenticated? can can attacker
> can take 0RTT data from session N, increment the resumption count, and
> replay that 0RTT data?

Crud, your right.  You broke that protocol in record time!  To make this
work with the existing TLS 1.3 spec, I think the server will have to
encrypt the ticket, which involves the whole ticket encryption key
management overhead.  Yuk.

> Since synchronization and authenticity are both required here, would it be
> simpler to use the sequence number and PRF state from the session? it can
> be saved by the client and server on session close, and they take off where
> they left things on any subsequent connection. That also gives clients and
> their users additional confidence in the protocol: the server can't just
> ignore things like resumption counts.

I prefer your solution, but it would require getting the TLS 1.3 protocol
changed.  TLS 1.3 seems to be geared towards making stateless resumption
with reusable tickets.

The issue seems to be that in TLS 1.3, tickets are reusable multiple times
to resume sessions, so we can't store the TLS sequence number in the
ticket.  If this were being used for an actual pre-shared key resumption,
it would probably be OK, but it seems to break security in multiple ways
when using tickets for TLS 1.2-style resumption, leaving us with no choice
but to emulate the continuation of the TLS sequence numbers (and PRF
state?  Is that needed?).

Another sort of warm and fuzzy reason I like this is that the whole thing
> resembles a single-long-running regular TLS connection over a single TCP
> socket. That makes things easier to verify, and some things easier to
> implement.

That's the idea... but hard to implement, and not at all documented.

> To see that this provides roughly TLS 1.2 security, note that so long as
>> the protocol never has to drop to 1-RTT, it is basically equivalent to TLS
>> 1.2 session-ID based resumption.  When we do drop down to 1-RTT, we will
>> replay 0-RTT application data, opening up new replay attacks.  However,
>> after this paper
>> <>, I do
>> not believe there are any significant new replay attacks against HTTPS,
>> ssh, or any real protocol I can think of.
> Unfortunately I don't think that's a safe assumption. The paper is about
> browser behavior, but there are API clients and SDKs that do not retry as a
> matter of design, they rely on TLS for non-replayability. In any event,
> there might be no problem: wouldn't it be a TLS library bug if the library
> somehow fell back to 1-RTT mode while also decrypting and passing on the
> 0RTT data? the client and the server need to agree on whether it was
> received.

This is worth more careful examination.  Each new protocol should be
analyzed for compatibility with session-cache based 0-RTT.  However, I have
not found any protocols that would have a problem.  Can you?

Protocols seem to fall into two camps.  The ones that require replay
resistance from the TLS layer all seem to terminate TLS connections in the
same place so that the session cache can be safely and efficiently
synchronized, avoiding replay attacks even when using 0-RTT.  For example,
when ssh-ing into a machine, that one machine terminates the connections,
and can have a shared cache.  None of the 0-RTT TLS-layer replay attacks
I've read seem to work against a single server-side session cache.

The other camp is HTTP-like protocols that terminate all over the place.
These all seem to be replay-tolerant because random network errors will
cause random replays, and there is no efficient way to synchronize the
session cache globally.