On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. Yes. So my question is whether there are an appreciably large number of servers each of which have an appreciably large fraction of *both* caching and non-caching clients to make an optimization like this worthwhile (servers which only have non-caching or only caching clients can just send or not send a ticket as appropriate) -Ekr > > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
