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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
