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

Brian Smith <> Sun, 19 July 2015 20:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A1121A894C for <>; Sun, 19 Jul 2015 13:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bTYXNcvGT2l8 for <>; Sun, 19 Jul 2015 13:17:11 -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 876741A8948 for <>; Sun, 19 Jul 2015 13:17:11 -0700 (PDT)
Received: by oigd21 with SMTP id d21so55746683oig.1 for <>; Sun, 19 Jul 2015 13:17:10 -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:date :message-id:subject:from:to:content-type; bh=yeR/I9pj9fq1q3Vmb6kd2Wg+6uu0YQO159rJ9/ndNMQ=; b=U3YpWCK+SkMgQZ93uW7Yw9/j6emOH7r7NveYBEeKDUWmNmAzKo56y2K1aOfnIOiYn7 BwsYWtES4AaYhA4yhCbvxtSCUyfZkjqGLHUuI3I+vsqL2bvNeU5U4MUSWLadj/2TI7+O zg/6Bu/kuBCJOF2VlrYVgN29Sxoz8ghUADHWVtywCQ0oHoxf9Al91diiBzaqIkYeob+f uPg8NmBtV32dpbRGUd2FjBPp/ZV754qU8ZQcmsMLlf2VTpdavvLFoYcQc0SAnQSKupZg 94/2shWbBucBi2YcyhDEYJDOe5SB5JNJ/bSuSfy/SthTFlv2aVskxflMwNb3JQ+HwMIN 6pdA==
X-Gm-Message-State: ALoCoQmv2KoKZJ5/HuxRHQ3Fg1tEJhBq472gnPk0uEzn+sxcQ6MDOHEdrl5VdWoblx/Wm2zUQZ3X
MIME-Version: 1.0
X-Received: by with SMTP id b132mr21825964oia.125.1437337030661; Sun, 19 Jul 2015 13:17:10 -0700 (PDT)
Received: by with HTTP; Sun, 19 Jul 2015 13:17:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20150719125016.GA17542@LK-Perkele-VII> <> <>
Date: Sun, 19 Jul 2015 16:17:10 -0400
Message-ID: <>
From: Brian Smith <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="001a113d3e0222a4aa051b401be1"
Archived-At: <>
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: Sun, 19 Jul 2015 20:17:13 -0000

On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni <>

> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
> > I'm not seeing a lot of value here. Remember that servers are not
> > required (and have never been required) to do session resumption, but
> > much of the overhead of doing it (having to have a database, session
> > ticket machinery) is associated with being willing to do session
> > resumption at all, so if a small fraction of clients would tell
> > you that they're not interested in resumption, it's not clear that
> > buys you much.
> >
> > Are there any server operators who think this is a useful feature
> > and can explain why?
> These days, I'm operating servers that only support session tickets
> (no server-side cache).  If the client does not send the session
> ticket extension, no session is cached.
> So for servers that elect the same strategy, there's no need for
> a separate means to signal the client's intentions.

First, I think that there should be only one way to do resumption in TLS
1.3 anyway. All I'm asking for is that the client have some way of
indicating whether or not it supports resumption. Viktor's method seems
fine with me.

Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
actually contains a regression here. It seems like it is no longer possible
for the server to indicate how long a PSK should be held by the client to
resume a session, and it seems like it is no longer possible for the server
to indicate that it doesn't support resumption.

I don't know that the lifetime hint is valuable, but being able to reduce
attack surface by being disabling resumption for a session seems clearly
useful. See, CVE-2014-1490 in
Firefox/NSS, and CVE-2015-1791 in OpenSSL, which show that it can be useful
to avoid resumption in many cases.