On Fri, Oct 11, 2019, at 14:07, Viktor Dukhovni wrote: > * The client has a what it believes to be a valid ticket > and is willing to re-use it, and would prefer to avoid > the cost of replacing it on each resumption. > > * The server is happy to allow re-use of still valid > tickets by clients, but needs to know whether the > client wants a new ticket (because it never re-uses). > > * The server would like to vend a new ticket only when the > old one needs to be refreshed (ticket lifetime or STEK > rotation). > > In the context of the draft as-is, such a client and server > have a time arriving at a mutually compatible configuration.
Yeah, I agree that this is a little thorny. However, the client asking for one extra and the server vending one more is a relatively small extra expense AND we discourage reuse in the general case. So, at least from my perspective, this isn't that serious a problem and shouldn't block publication. I'm not especially happy with the idea of having 1 mean "maybe 1". Having 1 mean 1 is far less dangerous. I think that I would prefer to go for an application- or configuration-level signal for this, if it is an important use case to consider. It's not like it is impossible to have an client say "I really need a ticket" at the application layer, and the server to receive that and call `tls.send_ticket()` (that's a function that NSS provides, for instance). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
