Re: [TLS] 0-RTT & resumption

Eric Rescorla <> Tue, 04 August 2015 12:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABA631A888E for <>; Tue, 4 Aug 2015 05:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sE8VimEx22Hc for <>; Tue, 4 Aug 2015 05:41:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D7C51A8889 for <>; Tue, 4 Aug 2015 05:41:29 -0700 (PDT)
Received: by wijp15 with SMTP id p15so4140584wij.0 for <>; Tue, 04 Aug 2015 05:41:28 -0700 (PDT)
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:from:date :message-id:subject:to:cc:content-type; bh=sZarvpVz+IKe+6l6eIvND8kerzAkCXjXpwecEhy6J5I=; b=ljhFBMqDeDMVRJDFEniJr6bK31T59rXMJHyOOY9c7V0fzqRwwtySKYnO6MO7T13OEj ZpYrsShKV4VilSUi3+ZGP/EGA30P0N9W9JTsgyAjQ3frTPuFkfGwDpK4qSRTsLEIYs7N ss/HudIENxKCbdzBwrIQkuiOzEv8w9kq90/8vIzwhaMtnmvvUzLYMn6el41m1L0bWjpN giU/SooS7vQCb0TvIc0t9uRrzVij9ar96wA+TWcCD9PYliK8ofMJCJ2z9lT5hl5SZMGA 5sX7cAfXwPf2KLpLH9BHQ9UKgYGBzB208VVggBVOUgVrMA/48yhY1BZ2DKe+LaRnr0W2 Qx8g==
X-Gm-Message-State: ALoCoQmQGb2M2t7xUg1J5M5QDtN3FzE3fuE+QxDSWrkxbEXVb7EIo33puChfamqLJek8zcVlXbrO
X-Received: by with SMTP id o20mr7694294wiv.31.1438692088014; Tue, 04 Aug 2015 05:41:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Aug 2015 05:40:48 -0700 (PDT)
In-Reply-To: <20150804065149.GA27148@LK-Perkele-VII>
References: <> <> <20150804065149.GA27148@LK-Perkele-VII>
From: Eric Rescorla <>
Date: Tue, 04 Aug 2015 05:40:48 -0700
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="f46d0435c06ad8fc1b051c7b9af9"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] 0-RTT & resumption
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: Tue, 04 Aug 2015 12:41:31 -0000

On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <> wrote:

> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote:
> >
> >
> > We agreed on how to do this in Prague. The sticking point was
> establishing
> > the cipher suite. I have WIP text on my machine for both of these which I
> > will be
> > sending early next week, once I get enough sleep to be able to clean it
> up,
> > so I'd ask people to sit tight till then.
> >
> Okay, now the PR (#211) seems to be up, let's review

Oops. It wasn't supposed to be done. I meant to make it a PR against my
own branch so that I could get early comments from MT, but obviously that
didn't work out. Regardless, thanks for your comments.

- Lacks client-driven client authentication[1]. All client auth is server
>   driven, which I think isn't very useful in real world (there are all
>   sorts of bad hacks[2] trying to work around lack of client-driven auth).

This is just extending existing practice for 1-RTT handshakes.

I tend to agree with you that it would be good to change that, but I didn't
to do that in this PR, because it would be a big semantic change in TLS.
I suggest you start a new thread on this topic, or perhaps add it to
client auth thread?

- EncryptedExtensions looks to be mandatory in some exchanges, optional
>   in others. I agree it should be mandatory in all (issue #213).

Me too. That's just editing error.

> - "The client's cryptographic determining parameters match the parameters
>   that the server has negotiated based on the rest of the ClientHello."
>   ... Does that mean the client has to guess what ciphersuite the server
>   will choose (more than pure-PSK vs. GDHE, which is unvaoidable with
>   just one encrypted block)?

The client knows what the server selected based on his previous offer and
the server's configuration (which by hypothesis is still extant) so the
should choose the same value again.

> - Am I reading the syntax wrong, or does the extensions field in server
>   configuration only allow exactly one extension (shouldn't it be zero
>   or more)?

Yes. good catch.

Also, regarding issue #212, unless the Certificate is handled specially,
> it would mean that the signature does not cover certificate. And not
> signing the certificate (esp. the public key within) causes problems
> in some exotic cases (I don't know if any of those cases pop up in TLS
> 1.3).

This seems like a good argument.

> I think it would simplify the security analysis a bit if CertificateVerify
> was always immediately before Finished and covered everything before that
> point.

Isn't this always the case presently? Are you just thinking we should say
a rule?