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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
