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

[Daniel Migault <[e-mail]>]

On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla <[e-mail]> wrote:

> > 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.
>
>
This statement seems wrong to me as TLS 1.3 does not provide such position.
Appendix C.4 discourages tickets re-use when Client tracking is a concern.
The section uses SHOULD and not MUST. So, in fact, TLS 1.3 takes position
this is not mandatory to renew tickets. As you mention, this position is
for good reasons, that is the consideration of other use cases than the web
browsing use case, and I also tend to agree with you we should not go
beyond what TLS 1.3 says - that is: not necessarily preventing ticket
re-use.

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