Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

Martin Thomson <> Mon, 13 April 2015 17:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E9261A1A15 for <>; Mon, 13 Apr 2015 10:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lYRYVX2d-PAd for <>; Mon, 13 Apr 2015 10:02:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA1ED1A19E9 for <>; Mon, 13 Apr 2015 10:02:43 -0700 (PDT)
Received: by oiko83 with SMTP id o83so9534097oik.1 for <>; Mon, 13 Apr 2015 10:02:43 -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:content-type; bh=QGXUPBajTIFmUjDyRA5PCx0BXMSbYOyhtL4aYVmC6XA=; b=A1GZRI3lidu4XIP/YfjDsImzc/OrrVHLTB566EjlXh7cokCnjUZhY10OvLSRczXJqx HclXnJ16ecj0r5z7wuHbdYSiF8wEXYoKx9mr75yj+kMwz5/sxNS+bLHxh1uWzfMnMOd1 WtVs9dABlhxNGysjwtHT52BnkMvAI53WBw7+Yaji1PJvuLWLgQAkanNyPWaa/KPwolFP xPs5+jpaeTQvxvdaGjmlfQKPmfBP39HzI/l3KfilfvvAND9klqWsb28xeAgMgNP1xEYB K8jI15pEc2uYFiN3wgoZBAJLof90gn7OMkk7S4Km04igKR0qlf3otpK8GmJ/U9VJKVjH qjQA==
MIME-Version: 1.0
X-Received: by with SMTP id y200mr8041607oif.20.1428944563449; Mon, 13 Apr 2015 10:02:43 -0700 (PDT)
Received: by with HTTP; Mon, 13 Apr 2015 10:02:43 -0700 (PDT)
In-Reply-To: <20150412165542.GA19481@LK-Perkele-VII>
References: <> <20150412165542.GA19481@LK-Perkele-VII>
Date: Mon, 13 Apr 2015 10:02:43 -0700
Message-ID: <>
From: Martin Thomson <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)
X-Mailman-Version: 2.1.15
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: Mon, 13 Apr 2015 17:02:45 -0000

On 12 April 2015 at 09:55, Ilari Liusvaara <>; wrote:
> 1) What is the recommended 0-RTT API model on server side
    (also consider server apps or app implementations that don't
   support 0-RTT)?

This would have to be similar to the client one, which if you recall was either:



   client.onunreliabledatalost = () => tls.send(unreliable);

You would have to have the server opt in either with:



   server.onunreliabledata = data => { /* handle it */ }

I hope my javascript isn't too obtuse.

> 2) What are the semantics of successfully received 0-RTT transfer
   (especially considering the client-side autoretransmit on

This is protocol-defined.

But I imagine that this depends on the model we employ.  Replayable
data could just be consider the start of a stream.  On the other hand,
unreliable data doesn't work very well for a stream mode.  Conversely,
replayable data makes no sense in a datagram mode, but all data is
unreliable there.

>  3) How does 0-RTT interact with ALPN (especially considering
   potential for multiple protocol candidates)?

I imagine that the ALPN from the previous session applies.  If the
client wants to change anything, it probably shouldn't use 0-RTT. Note
that this includes cipher suites and maybe other extensions too.

>  4) Can handshake with attempted 0-RTT be securely downgraded to
   v1.2 (obviously causes the 0-RTT to fail)?

Not safely.  The decision we made at the last meeting (or interim, I
can't remember) was to require that the server make a commitment to
support - or at least to ignore - TLS 1.3 handshake for at least the
validity period of the 0-RTT information.  The 0-RTT messages might be
ignored in DTLS, but they are unlikely to be handled cleanly by a TLS
1.2 implementation.  I would expect a fatal error.

>  5) There is potential footgun if 0-RTT is used with (DH-)PSK: The
   PSK authenticates the connection immediately, but 0-RTT is
   as replayable as ever. What to do with that?

How is that materially different to other suites?

>  6) The same as above, but when attempting to resume a session.
   with a client certificate (since cc is property of session)?

As before, if the information is replayable, then it needs to be
understood by both parties that it is replayable.  And both need to
understand how that is not a concern.  The client certificate doesn't
present a special risk here.  At least not as far as I've been able to

> 7) What guidance to give regarding what data can be put to 0-RTT,
   considering its replayability?

What guidance do you want?  It's replayable.  If it causes something
to happen that you don't want to have happen twice (or more), then
don't use 0-RTT.

>  8) If resumption attempt has 0-RTT data, what keying material is
   used for the 0-RTT?

That combination might not be valid.  If it is, I'm guessing that the
first client flight is encrypted and authenticated as a "normal" 0-RTT

> 9) Can server roll over its 0-RTT keys without waiting for the
   previous ones to expire?

Yes, there will need to be a key identifier in the clear that allows a
server to identify which key to use to decrypt the client's flight.

>  10) How is attacker establishing a session (or at least decoding
    server's first application flight) replaying captured
    0-RTT data prevented (since that could leak quite a bit of
    info about what's in 0-RTT blob)? Or not?

Well, the attacker presumably doesn't have the private keys used by
either client or server.  They might be able to cause a replay, but if
we have decent crypto, they aren't able to decrypt anything, nor can
they continue the session.