Re: [TLS] TLS 1.3 - method to request uncached shared secrets

Eric Rescorla <> Mon, 20 July 2015 04:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 546E41B2F86 for <>; Sun, 19 Jul 2015 21:28:29 -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 pXNfQwVhc9Mx for <>; Sun, 19 Jul 2015 21:28:27 -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 059D51B2F87 for <>; Sun, 19 Jul 2015 21:28:23 -0700 (PDT)
Received: by wgmn9 with SMTP id n9so121118761wgm.0 for <>; Sun, 19 Jul 2015 21:28:21 -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=Fl9aDpZc51XtXdewEKh4gJbWak32HlAgYr12wzRgjPM=; b=GIfGitiV7iTzSOtc0IZSFFLunVaOODZJfmqCLNvoQ3SNAZnv4n+5HJ0uh4OAKR2J4s 07GS7T3RaMX/Yfbhf+NAcXEoJYXwj1s45Thl/fvWZVz4ls0qK5VFbBjEZmwTg3yVd4mV 6vNQzxG13fDVWRk/h6SVik1cyNvIXWcVxlgnR1abeiwjAKibbm88cDmZNIsLO70LFvrP 8nD/TYGCqKrq4wpawChhwtU27A/Bq72uiSz8d+96i13ZEIZk5v9ijqa68Q8SqRdRWlKM PHnU+l8R8z8nPtoS1D56d7H0Ia40wysbC4BBHc8fhcyjhWEWqLvskOlZRN25u5Dt8f++ Ve3Q==
X-Gm-Message-State: ALoCoQn4eOPloUP5GWaph4RWc+FvsVKGj4WUQh7CKe+VlWxY92Tz8uqHu9ZyjyRHjCngodBlDqXH
X-Received: by with SMTP id wr10mr51231628wjb.81.1437366501638; Sun, 19 Jul 2015 21:28:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 19 Jul 2015 21:27:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20150719125016.GA17542@LK-Perkele-VII> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 20 Jul 2015 06:27:42 +0200
Message-ID: <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary="089e013c6478be1faf051b46f72e"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets
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, 20 Jul 2015 04:28:29 -0000

On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith <> wrote:

> Eric Rescorla <> wrote:
>> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <>
>> wrote:
>>> It seems weird that the server can supply a lifetime hint but the client
>>> can't, especially in cases like WebRTC where there is no functional
>>> difference between the two. But, that's a smaller issue than the lack of an
>>> indication that resumption machinery isn't wanted at all.
>> I don't think it's *that* odd, since tickets have at least two fundamental
>> asymmetries:
>> - The client needs to actually keep state and the server does not
>> (that being the point of tickets)
> It depends on how the server implements tickets. The server could
> implement tickets the same way that it implements session ID-based
> resumption. That's not a good idea, but I don't think the spec should
> prohibit that type of implementation either since it unenforceable.

I don't think that the current spec does so.

> Thus, because of that possibility, it is valuable to have the client be
> able to say "don't cache the session" and/or limit the session's lifetime,
> so the client can help direct the level of forward secrecy for the session.
> Right now, only the server has a say in how long a session will be
> forward-secret.
> Note also that the NewSessionTicket extension precedes any application
> data, so without a way to prevent an unwanted NewSessionTicket message from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.
> Anyway, I don't understand why you keep directing your question to server
> vendors. The people that would be interested in such a feature are client
> software vendors, for client software that wants to control the level of
> forward secrecy for a session.

I think perhaps you have misunderstood the forward secrecy properties of the
current draft. Unlike TLS 1.2 and previous, the current draft has a separate
resumption master secret which is independently derived from the master
secret used for the connection keys in the original connection. This means
that if you don't resume the connection, you have forward secrecy for the
original connection regardless of whether the server stores the session in
the session cache or sends the client a ticket.