Subject: [Emu] Session tickets in draft-ietf-emu-eap-tls13

From: Alan DeKok <[email-masked]>
Date: Thu, 4 Mar 2021 12:49:16 -0500

There has been previous discusson about the number of session tickets.
This discussion needs to be revisited, as the request to update the
document was rejected for erroneous reasons.

RFC 8446 Section C.4 gives guidance on this exact issue:  How many
session tickets should be used for an application which uses TLS.

https://tools.ietf.org/html/rfc8446#appendix-C.4

   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.

EAP-TLS will only be using one connection.  There is no way to use
multiple EAP "connections" over the same media.  As such, RFC 8446
suggests that only one session ticket is appropriate.

The recommendation to use one session ticket by EAP-TLS does not
require checking with the TLS WG, because this use-case was already
anticipated, and explictly permitted by them.  This recommendation is
not making recommendations about TLS 1.3 internals, and no supporting
evidence was given for that claim.  This recommendation does not make
EAP-TLS incompatible with TLS implementations, and there was no
supporting evidence given for that claim, either.

Both RFC 8446 as a standard, and OpenSSL (as an example
implementation) permit an application to change the number of session
tickets used by TLS.  This change uses public APIs in a manner
permitted by the specifications, in the same way that many other
protocols use TLS.  The opposite position dismisses a technical
position based experience with implementation and deployments.  That
position is contrary to the publicly available specifications and
implementations.

Off-list discussion among the implementors indicates that there is
consensus to send, and store, only one session ticket.  There is
consensus that EAP peers will only ever use one session ticket at a
time.

It would be beneficial to have the document reflect EAP-TLS as
implemented.  It would be beneficial to have the document reflect the
recommendations of RFC 8446.

I suggest therefore that the draft be updated to reference RFC 8446
Section C.4 in respect to this topic.  Also, that the draft require
the EAP server sends only one session ticket.  And that the EAP peer
expect only one session ticket.  And that if more than one session
ticket is received by the EAP peer, that it chooses to save one and
discards the rest.