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

[Eric Rescorla <[e-mail]>]

> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
>
> > 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.
>
> Indeed I agree that ticket reuse is often undesirable, and expect that
> it will be avoided in many cases.  So I am somewhat sympathetic to the
> above as a starting point for the analysis.
>
> That said, I don't see that making reuse easier to negotiate is likely
> to create significant opportunities for misuse.

I'm actually making several points here:

1. TLS 1.3 takes the position that reuse is bad and that position
   is for good reasons, so we shouldn't undercut it in a new
   extension.

2. Creating a mechanism which encourages reuse increases the risk
   of reuse.

You are responding to number (2), and I'll respond to that below,
but I think the controlling point is actually (1). We shouldn't
encourage reuse, period.


>     - Both the client *and* the server would need to opt-in to reuse.
>
>       * Even if the client asks for reuse, the server can invalidate
>         the old ticket (something it would need to be able to do
>         already to ensure non-reuse) and send a fresh one anyway.
>
>         The client would have to replace the old with the new, since
>         it has to assume that the old is now likely invalid.
>
>       * Even if the server is willing to reuse, if the client asks
>         for a new ticket, the server has to assume the client has
>         a single-use cache, and should vend a new ticket.
>
>       so it takes bilateral coordination to arrive at reuse, and
>       so accidental reuse in applications where it is inappropriate
>       requires errors on both ends.

The issue is less accidental reuse than joint misconfiguration (e.g.,
bad defaults or bad advice in some Stack Overflow document).



> > 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.
>
> Postfix has a shared cache (indexed by destination domain+mx host) for
> multiple independent processes racing to use the cache to make remote
> SMTP connections.
>
> Frequent writes to that cache create measurable overhead and still don't
> prevent reuse.

I'm sorry to say that I'm not that sympathetic to this position. I
appreciate that it's inconvenient for Postfix to have frequent writes
to the ticket cache, but what you propose to do is hoist this
implementation idiosyncracy into the specification, and I don't think
that that's a good tradeoff, both for complexity and because the


> Transmission of unnecessary tickets is also wasteful of
> network and other server resources.

Well, my position here is that these tickets aren't unnecessary,
because you should be using them, rather than violating the
SHOULD in the 8446.


> Erasing tickets on first use would be unwise, most existing servers will
> not presently return a fresh ticket on resumption.

This seems like a defect in those servers. However it can be handled
by not erasing tickets until a new ticket is provided.


>
> > 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.
>
> This is an interesting idea, but how would the two extensions interact?

I would imagine the logic would be:

If !reuse || !present(reuse extension) {
  send min(max-local-tickets,
           tickets-requested-extension-present ?
           tickets-requested-extension-value :
           1)
}

> And wouldn't that interaction add more complexity?

Perhaps. At least in NSS, I imagine it would be pretty comparable, assuming
we opted to implement the non-reuse one at all.


> By hypothesis
> clients that are willing to reuse tickets don't really need more than
> one at a time. Is there a clear use case for multiple concurrent
> reusable tickets.

Yes, I see your point here. I don't have a clear case for this, but
I'm also not sure that there isn't one: concurrent usage and serial
usage are not necessarily the same.


> > Thus, I would prefer to advance this document as-is.
>
> Thanks for the substantive response.  Much appreciated.  I hope you're
> willing to address the above reaction, I am trying to find common
> ground that addresses your concerns and mine.

And thank you for your substantive response. I am not sure if we will be
able to
find common ground however.


-Ekr