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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
