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

[Viktor Dukhovni <[e-mail]>]

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

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4

       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:

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11

       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 6.3.1.5.4) and supplying a suitable PSK cipher suite.

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

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

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

and

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4

       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;

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

-- 
	Viktor.