On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <br...@briansmith.org> wrote:
> Eric Rescorla <e...@rtfm.com> wrote: > >> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <br...@briansmith.org> >> wrote: >> >>> 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, >>> >> >> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint >> value. >> >> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12 >> >> and it seems like it is no longer possible for the server to indicate >>> that it doesn't support resumption. >>> >> >> Well, it can't indicate it, but if it doesn't supply a session ticket, >> there's no way for >> the client to do it. >> > > Great. I was misunderstanding. Here's the part that is not is still not > clear to me: Is the SessionTicket extension still to be used or not? 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. > No, it's not used. 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. > I don't think it's *that* odd, since tickets have at least two fundamental asymmetries: - The client needs to actually keep state and the server does not (that being the point of tickets) - The client (because they speak first) gets to offer the ticket for resumption and the server can accept it or reject it. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls