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

[Eric Rescorla <[e-mail]>]

I would make several points here:

1. RFC 8446 explicitly discourages ticket reuse
   (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
   should not be designing an extension to enable reuse. While it's
   potentially true that some applications do not benefit from
   non-reuse, creating a set of mechanisms around reuse risks those
   mechanisms being used in settings where reuse would be
   bad. Moreover. just because at present sending MTAs have weak
   privacy properties does not mean that we should bake in this
   situation permanently.

2. The additional cost of multiple tickets seems extraordinarily
   small, so I am not at all persuaded that there is enough value in
   this use case to justify adding new protocol machinery, even
   ignoring point (1) above.

3. If there *is* such value, then you can register your own extension
   which allows you to say the orthogonal thing, namely "don't send me
   any tickets at all if you are resuming". This would be more
   flexible in that you could then say "I would like 10 tickets, but
   only if you don't resume". Note that
   https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would
   allow you to do this efficiently.

Thus, I would prefer to advance this document as-is.

-Ekr











On Mon, Jan 20, 2020 at 9:54 PM Viktor Dukhovni <[e-mail]>
wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>