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

Viktor Dukhovni <> Sun, 19 July 2015 21:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A60091B2C8D for <>; Sun, 19 Jul 2015 14:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0cagp0eeimLB for <>; Sun, 19 Jul 2015 14:03:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93B0B1B2C7A for <>; Sun, 19 Jul 2015 14:03:57 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 9C03D284B6C; Sun, 19 Jul 2015 21:03:56 +0000 (UTC)
Date: Sun, 19 Jul 2015 21:03:56 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <20150719125016.GA17542@LK-Perkele-VII> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 21:03:59 -0000

On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:

> Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not?

While we now have

       In TLS 1.2 and below, this functionality was provided by "session
       resumption" and "session tickets" [RFC5077].  Both mechanisms are
       obsoleted in TLS 1.3.

at the same time we also have:

       After the server has received the client Finished message, it MAY
       send a NewSessionTicket message.  This message MUST be sent before
       the server sends any application data traffic, and is encrypted under
       the application traffic key.  This message creates a pre-shared key
       (PSK) binding between the resumption master secret and the ticket
       label.  The client MAY use this PSK for future handshakes by
       including it in the pre_shared_key extension in its ClientHello
       (Section and supplying a suitable PSK cipher suite.

	 struct {
	     uint32 ticket_lifetime_hint;
	     opaque ticket<0..2^16-1>;
	 } NewSessionTicket;

	  Indicates the lifetime in seconds as a 32-bit unsigned integer in
	  network byte order.  A value of zero is reserved to indicate that
	  the lifetime of the ticket is unspecified.

	  The value of the ticket to be used as the PSK identifier.


       The pre_shared_key extension is used to indicate the identity of the
       pre-shared key to be used with a given handshake in association with
       a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).

         opaque psk_identity<0..2^16-1>;

	     struct {
	       select (Role) {
		 case client:
		   psk_identity identities<0..2^16-1>;

		 case server:
		   psk_identity identity;

	     } PreSharedKeyExtension;

	  An opaque label for the pre-shared key.

So indeed it is no longer possible for the client to signal the
ability/desire to resume sessions, and servers will generate session
tickets absent any indication that the client intends to use them.

This does not impose a space penalty on the server, but some CPU
and bandwidth may be wasted on clients that don't or can't resume.

> It seems not, AFAICT. If the SessionTicket extension were to be used, then
> everything would work perfectly as Viktor suggested in his message: the
> absense of the SessionTicket extension in the ClientHello would be the way
> that a client can indicate that it doesn't want the session to be cached.

In the current 1.3 draft, there is indeed no client signal.

> 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.

The client lifetime is not that useful with session tickets anyway,
whether the client caches at all, could be, but it is not clear
that the resulting "inefficiency" needs to be fixed.  The fix would
be for the client to send an empty extension of some sort to signal
its desire to elicit a session ticket.