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 

TLS mailing list

Reply via email to