Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Viktor Dukhovni <[e-mail]>]

On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote:

> On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
> > Regarding Viktor's suggestion, I personally believe it would increase the
> > complexity of the proposal, and I don't see use-cases compelling enough
> > to warrant that complexity. I would rather keep this proposal as simple as
> > possible.
> 
> I see that I didn't respond to this.  I support David's view.
> 
> Even the suggestion that clients that resume only request one assumes
> that clients only want one.  The client probably knows better than we
> do.  I would rather say nothing about the number and keep it simple. 0
> means 0, 1 means 1, N means N.

The proposal has since been simplified. With 1 meaning 1, 2 meaning 2,
...  The only change is that 0 and 255 become special, with 255 meaning
definitely no tickets, and 0 meaning tickets only if the server sees a
need a replace the presented ticket.  Otherwise, the client has no way
to request refresh only if needed, and must ask for 1 just in case.

Unnecessary tickets are a waste server and client resources and
bandwidth, and make external caches "hot" on clients that are perfectly
fine with a slowly changing series of multi-use tickets.


> FWIW, the cost of oversupply is often marginal, depending on
> circumstances.  In a client-speaks-first protocol with no client
> certificate, the server can occupy the first round trip with tickets
> and generally gain a performance advantage (as sending more will
> increase the congestion window in most cases).

This is useless for clients with just a single mult-use slot in their
ticket cache.  Not everything is a web browser.

> Otherwise, there are usually quiescent periods that can be exploited
> for sending tickets.  And tickets are small, and cheap to generate.
> With one exception: if you are relying on client authentication and
> packing that into tickets, I'm sorry.

There's no need to exclude valid use-cases.  The refined proposal
is rather non-invasive, and handles this case cost-effectively
on clients that re-use tickets (and don't use early-data, ...).

-- 
    Viktor.