Re: [TLS] Forward secrecy with resumption, and 0-RTT security

Bill Cox <> Sun, 06 December 2015 20:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A44B01B2B4F for <>; Sun, 6 Dec 2015 12:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z7jZ6abN-XGu for <>; Sun, 6 Dec 2015 12:30:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BC881B2B4E for <>; Sun, 6 Dec 2015 12:30:15 -0800 (PST)
Received: by ioir85 with SMTP id r85so162980075ioi.1 for <>; Sun, 06 Dec 2015 12:30:14 -0800 (PST)
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=G54/O/zt1bAxe2rUAqFZtd5Va0OPFCt5CZAk82jf6IY=; b=JgOzDtC9vQL0KnkvMmZ2N9dZHWJTMYTD01gIceeJDkW9bWjC1Re+k3az+dkgOVA3ij rdwjdpnkccaWmbWgGJCVQ0y4S/x50OZfyvjxbdSHmy7ysQNg7Hv7PYbVgGHLzjpBbH1g +5mkzJZj1xA81CmYtoLsKWU0EQdAh6KmjzexvREv7OGI7wIZsTHNVd/dmSjoURFvhcT1 PT55ECoq54MV9fvxflITX4M1Wg87ifIIf1k0i3IO1T8tuVtTPpYvcTUQCrOIG68EM7FO Zx5TndRecdZphC3ePRIhDMIE6JncXRPuYXwE1wFc2NxwDIYP229AcCiK1pqTXNzsw87Q Vn+g==
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:content-type; bh=G54/O/zt1bAxe2rUAqFZtd5Va0OPFCt5CZAk82jf6IY=; b=f5Dy16QAoh24E4hXq3AZv9Vqp61oSEVlOr37q1CZjdZIEYISy+21ceYJ4SXbHTE/Q1 l2FpOfeBt9ztyUwu2Efxt6c9JQ1l9R4BMcCTuMH/VMuQSM2BvZijIx08T1bvObqy6FCQ tBlfmLTqkWV9GlqWTKY9ZRnGOXST5xtsZbbbvieUHwgks7nA3Clgdxao8SRybBwSlNXB EV+/1czgDfdcjuk3bJTuol5DZmn8+cVl2l24Q+gllsOplTg+19Y6b/FEwyIqKNfGix7b en1PtLGbB2e3f8peuLzAWQuNzx8ejPe1dpzBf94xpqnYlO6439cCH9m2RTJhGTYIxBRP o5+g==
X-Gm-Message-State: ALoCoQn8HDjrqxDjzY9P3MkVSsLgW36JqKz4EUDuTvCcwxUuzvBRzbsugBDvZEOFWjCV21k26DXV
MIME-Version: 1.0
X-Received: by with SMTP id a127mr23863615ioe.60.1449433814658; Sun, 06 Dec 2015 12:30:14 -0800 (PST)
Received: by with HTTP; Sun, 6 Dec 2015 12:30:14 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 06 Dec 2015 12:30:14 -0800
Message-ID: <>
From: Bill Cox <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a1140e69ea647d20526409b6f"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security
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: Sun, 06 Dec 2015 20:30:16 -0000

On Sun, Dec 6, 2015 at 11:39 AM, Eric Rescorla <> wrote:

> With PSK-DHE over 0-RTT, would we use the static DHE server share for the
>> first resume flight?
> No. In All PSK-DHE modes, the PSK is used as SS.

That's cool.  I need to re-read the spec more carefully.

>> You're talking about the single byte that indicates an empty session id?
> That doesn't seem like
> it's a big source of inefficiency.

Ah... I did not realize it is u8-length encoded.  One byte bothers me a lot

> I guess another question is: Do we care about strong client authentication
>> enough to support it in a 0-RTT world?  The default solution when using TLS
>> 1.3 is for companies that use security keys to never use 0-RTT
>> authentication.  That's not the end of the world, but I imagine that having
>> to support 0-RTT for regular users, and forcing 1-RTT for employees and
>> users who choose a higher level of security is going to be a complication.
> Yes, I think it's important, especially for WebRTC.

OK... one more spec to read.

>> I still think some more text describing 0-RTT implementation techniques
>> would be a good thing.  It really does read as if the spec is saying that
>> servers SHOULD NOT support 0-RTT.  I've never read a security warning like
>> that which did not have a SHOULD NOT associated with it.  Of course, I
>> haven't read that many IETF specs yet :)
> I'll but it on my TODO list but I would definitely welcome a PR here.
> Thanks,
> -Ekr
> I'll see if I can put together some text that would help me understand a
bit better, though as you can see from my emails so far, writing is not my
strong suit.