Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

["Martin Thomson" <[e-mail]>]

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).