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

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 09:08:17 -0800

> 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

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Feb 2020 13:04:48 -0600

> that that's a good tradeoff, both for complexity and because the

We've done this a lot though, haven't we.  For example, we've striven to
avoid reconnects because SChannel can't really handle them.

So I'm not that sympathetic to not being that sympathetic to specific
implementation issues.

Nico
--

---

From: Daniel Migault <[email-masked]>
Date: Sun, 2 Feb 2020 14:51:51 -0500

>    is for good reasons, so we shouldn't undercut it in a new
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.

> by not erasing tickets until a new ticket is provided..
>
>
> >
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Rob Sayre <[email-masked]>
Date: Sun, 2 Feb 2020 19:39:51 -0800

> . 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.
>

RFC 2119 is a bit stronger than that: implementations are not required to
interoperate with parties that violate the "SHOULD" (that is reserved for
requirements designated with "MAY").

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 20:42:55 -0800

> avoid reconnects because SChannel can't really handle them.

When we designed TLS 1.3, we paid a lot of attention to it being a drop-in
replacement for TLS 1.2. This required some tradeoffs. Given that this
issue already existed in TLS 1.2, I don't really see that that rationale
applies here.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 21:01:45 -0800

>> position this is not mandatory to renew tickets.
Somehow I didn't get Daniel's email, so responding to it here.

C.4 is not conditional. It simply says "Clients SHOULD NOT reuse a ticket
for multiple connections." My point is not that servers which do not renew
are not compliant but rather that TLS 1.3 has taken the position that reuse
is bad and therefore we should not add an extension to facilitate it.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Feb 2020 00:49:15 -0500

On Sun, Feb 02, 2020 at 09:01:45PM -0800, Eric Rescorla wrote:

> My point is not that servers which do not renew are not compliant but
> rather that TLS 1.3 has taken the position that reuse is bad and
> therefore we should not add an extension to facilitate it.

Re: C.4  Clients SHOULD NOT reuse a ticket for multiple connections.
         Reuse of a ticket allows passive observers to correlate
         different connections.

But ticket reuse is patently a win when connection correlation is an
unavoidable and even desirable feature of the network relationship
between the parties.

Receiving MTAs strongly discriminate against direct-to-mx traffic from
dynamic IPs.  Sending MTAs on the public Internet strive to build up a
positive IP reputation, and operators only reluctantly shift traffic to
new addresses when the old must unavoidably be retired.

There is simply ZERO benefit from ticket churn.  Similar considerations
apply in many other "fixed endpoint" deployments.

What I hear TLS 1.3 telling me, is to eat the porridge, after all there
are starving children in Africa, and I must set a good example lest they
too refuse to eat.

If so, it seems I must stuff my application full of unnecessary tickets,
because someone somewhere might actually be a few tickets short...  If
so, this is regrettable.

-- 
    Viktor.

---

From: Rob Sayre <[email-masked]>
Date: Sun, 2 Feb 2020 21:55:03 -0800

> are starving children in Africa, and I must set a good example lest they
I do not understand this point.

> If so, it seems I must stuff my application full of unnecessary tickets,

I don't this is the case.

thanks,
Rob

---

From: Daniel Migault <[email-masked]>
Date: Mon, 3 Feb 2020 18:54:37 -0500

C.4 is clearly in a context where privacy is needed and by writing "SHOULD
NOT" TLS 1.3 takes instead the position there are some cases this is not
required.

"""

C.4 <https://tools.ietf.org/html/rfc8446#appendix-C.4>.  Client
Tracking Prevention

   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.
   Servers that issue tickets SHOULD offer at least as many tickets as
   the number of connections that a client might use; for example, a web
   browser using HTTP/1.1 [RFC7230
<https://tools.ietf.org/html/rfc7230>] might open six connections to a
   server.  Servers SHOULD issue new tickets with every connection.
   This ensures that clients are always able to use a new ticket when

   creating a new connection.
"""

-- 
Daniel Migault
Ericsson

---

From: Hubert Kario <[email-masked]>
Date: Tue, 04 Feb 2020 14:56:27 +0100

> unavoidable and even desirable feature of the network relationship

the thing is that getting extra ticket from the server is at most an
inconvenience for postfix

for other usages, reusing aticket may be a security breach

just by virtue of being defined, it will be implemented by some libraries,
which means in turn that it will be used incorrectly by somebody

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 4 Feb 2020 15:08:31 +0000

> inconvenience for postfix

Isn't the giving out of needless tickets a performance cost
for the server, as well as a bandwidth cost for the network?

Or are tickets zero-cost to produce?
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Feb 2020 16:47:02 -0500

> Or are tickets zero-cost to produce?

They are not free.  They can be modestly large, especially when client
cert authencation was used on the initial connection, in which case at
least the EE cert is typically bundled into the ticket (some
implementations may save the whole chain).

This means that abbreviated resumption handshakes are now followed
with potentially an additional O(1 KB) of ticket traffic.

The CPU cost of encrypting the ticket is generally modest, but in
an RPC protocol over TLS, which relies on resumption to ammortise
handshake overhead, the extra payload may dwarf the application
traffic.

Squirreling away a fresh tickets after each RPC request may also
increase garbage collection pressure in some languages.  Not all
the world is C, C++ or Rust.

-- 
    Viktor.