Subject: [TLS] Session resumption ticket reuse considered harmful

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 14:55:25 -0600

... unless both parties agree.  It takes two to agree.

What are the problems with ticket reuse?  Well:

1) session linkage

2) early data doesn't get rekeyed, so you get key reuse and the early
   data is replayable

In the case of SMTP, however, (1) is not a problem for obvious reasons,
and (2) is N/A.

For SUBMIT, (1) is a problem, so don't allow it, and (2) is N/A.

SMTP doesn't care about session linkage because it's MTA<->MTA traffic
that is already aggregating multiple users' traffic, plus email is
store-and-forward, so there is no real privacy loss for users.

Nico
--

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 06 Mar 2020 08:35:07 +1100

On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> .... unless both parties agree.  It takes two to agree.

RFC 8446 says:
   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.

Are you arguing that there are exceptions that justify not respecting the "SHOULD NOT", or that the "SHOULD NOT" is too strong?  Because no one is violating any specifications when they reuse tickets, just recommendations.

(In other words, I don't understand the strength and vehemence of the arguments being used.)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Mar 2020 21:40:24 +0000

I think several participants in these threads are taking SHOULD NOT re-use as a MUST NOT.  Servers in datacenters seem to fall outside that concern, no?

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 16:12:45 -0600

On Thu, Mar 05, 2020 at 09:40:24PM +0000, Salz, Rich wrote:
> I think several participants in these threads are taking SHOULD NOT
> re-use as a MUST NOT.  Servers in datacenters seem to fall outside
> that concern, no?

Indeed, RFC2119 defines SHOULD NOT:

   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
      there may exist valid reasons in particular circumstances when the
      particular behavior is acceptable or even useful, but the full
      implications should be understood and the case carefully weighed
      before implementing any behavior described with this label.

And SMTP and your use case have "valid reasons" because they are "in
particular circumstances when the particular behavior is acceptable or
even useful" and "the full implications" _are_ "understood" and "the
case" has been "carefully weighed".

Even if RFC8446 said MUST NOT, we could update it, but as it is we don't
need to because it does say SHOULD NOT:

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

and that makes very clear that the SHOULD NOT is specifically about
"Client Tracking".  And it follows that if you have an application that
doesn't find have a client tracking concern, then this SHOULD NOT should
be inapplicable.

The onus might be on us to demonstrate that there are use cases where
client tracking is a non-issue.  But it should be quite clear that there
are cases where client tracking is indeed a non-issue.

Now, maybe one might want to say that this is like PFS: we want to
always require PFS (and we do!), so we should always require session
ticket non-reuse.  That would require an update to RFC8446.  Note that
the issues with RSA key transport and the client tracking issues are
vastly different, and that's almost certainly why PFS became a hard
requirement while ticket non-reuse was only made a SHOULD NOT.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Mar 2020 14:49:23 -0800

> .... unless both parties agree.  It takes two to agree.

As far as I am aware session tickets being single use isn't enforced
by any server right now: it's a desirable but theoretical property for
0-RTT.

My skepticism is entirely a function of this being a late breaking
change to a relatively simple proposal, with not very much in the way
of quantifiable evidence to back up the concern that shared cache
contention is a big overhead. Is it 1%? .5? 10%? of the total time to
use a connection. At 10% we definitely need to do something, at .01%
we almost certainly don't.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 16:54:55 -0600

On Fri, Mar 06, 2020 at 08:35:07AM +1100, Martin Thomson wrote:
> Are you arguing that there are exceptions that justify not respecting
> the "SHOULD NOT", or that the "SHOULD NOT" is too strong?  Because no
> one is violating any specifications when they reuse tickets, just
> recommendations.

Good question.

RFC2119 is very clear about what "SHOULD NOT" means, and that is
different from "MUST NOT":

> (In other words, I don't understand the strength and vehemence of the

Well, suppose the RFC said PFS is a SHOULD, not a MUST, but we became
certain that PFS should be REQUIRED (same as MUST).  We could start
rejecting proposals that preclude that change to the RFC, and we could
go update the RFC.

If we liken ticket non-reuse to PFS, then the vehemence of opposition
we're seeing to any ticket reuse makes sense even though RFC8446 says
"SHOULD NOT" reuse tickets rather than "MUST NOT".

It is fair to boil this down to just a question of how strongly we do /
should feel about ticket reuse.

It would not be fair to exclude SMTP as an application from
consideration of whether ticket reuse ever makes sense.  SMTP does not
use early data, and SMTP between MTAs does not present the kind of
client tracking concerns that HTTP user-agents do.  SMTP is precisely
the sort of "particular circumstance" that RFC2119's description of
"SHOULD NOT" is about.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 17:08:22 -0600

> by any server right now: it's a desirable but theoretical property for

Is that so?  Will that remain so?

> [...]

What is late breaking to you?

The change was proposed during WGLC.  If before or during WGLC is too
late, when is it not too late?  At WG work item adoption call?

See also my post about feature matrix issues.

> [...]

Right, but this is where the "Postfix architecture" issue comes in.  I'm
having a conversation with him about this.  Viktor might be confused
about the CoW properties of LMDB, but in any case, the wire bandwidth
waste and server compute waste issues have nothing to do with Postfix's
architecture/design/implementation.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2020 18:15:26 -0500

> we almost certainly don't.

It isn't just the impact on client ticket cache processing, whatever it
might be.  Tickets can be quite large when client certs are in use,
because various TLS APIs promise server applications the ability to
return the client cert (or full chain) at the completion of the
handshake, which means recording the client cert or chain in 
the ticket.

And with PQ certs about to get substantially bigger than RSA certs, I
don't see why carefully designed servers and clients need to engage in
wasteful network traffic, CPU and I/O costs.

In the case of Postfix, the new ticket has to be generated, encrypted
and transmitted by the server, received and decrypted by the client,
then base64 encoded and transmitted to the tlsmgr(8) process, which
stores it an LMDB or Berkeley DB database, incurring I/O costs to
store it (likely also an fsync).

With spinning rust the MTA's throughput is largely limited by the number
of synchronous writes to disk per second, and additional synchronous
writes degrade overall throughput.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 17:24:56 -0600

> handshake, which means recording the client cert or chain in 

FYI, I accept that this is so, but IMO APIs should allow apps to, and
apps should, specify what to save in the tickets, so that we can have a
useful compression of the client certificate and chain.

> wasteful network traffic, CPU and I/O costs.

See above.

> store it (likely also an fsync).

Well, users should configure the ticket DB to land on tmpfs, or you
should force it to be so, since the DB is ephemeral.  Or just use an
in-memory DB if you don't need to share it.

> writes degrade overall throughput.

Meh.  It's the wire bandwidth and server cycle waste issues that
convince me.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Mar 2020 16:21:56 -0800

> late, when is it not too late?  At WG work item adoption call?

It depends on the relative size of the change and the importance of
the issue. An important central issue that went completely unnoticed:
unfortunate, but completely reasonable to require addressing, e.g. "we
did an experiment and it doesn't work". A large extension of scope, or
a seemingly small one that complicates everything? That hopefully gets
brought up early enough to not massively delay everything else. That's
particularly true when it's unclear what is actually needed to serve
the desired goal.

> architecture/design/implementation.

Tickets are small and issuance is cheap. Where are the *hard numbers*
to back up the assertions being made that ticket reuse is an important
savings?

Sincerely,
Watson

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Mar 2020 00:32:03 +0000

>    It depends on the relative size of the change and the importance of
    the issue.

It's a judgement call then, right?  And reasonable people may disagree.  But surely given the size of the PR size is not the issue.  And several folks say it's important.

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Mar 2020 18:37:20 -0600

> the issue. An important central issue that went completely unnoticed:

Thanks.  I agree about the relative size of the change, how substantial
it might be, and how necessary it might be.

> to back up the assertions being made that ticket reuse is an important

How small they are appears to be in question.  See Viktor's post.

Nico
--