Re: [TLS] Session resumption ticket reuse considered harmful

[Nico Williams <[e-mail]>]

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