Requiring per application data in session ticket seems wrong

[huitema]

In the new section 5.4. of the transport draft, "Required Operations on Connections", we see a requirement that When implementing the server role, applications need to be able to:

o ...

o if Early Data is supported, retrieve application-controlled data from the client's resumption ticket and enable rejecting Early Data based on that information.

I read the corresponding text in the HTTP draft, and I understand that the idea is to remember the HTTP Settings when resuming an HTTP connection. That's fine, but it seems to assume that tickets are tied to a specific ALPN. Otherwise, if a server supports several applications over the same port, then the clients need to keep track of the ALPN used when the ticket was received.

There is no such requirement in TLS 1.3 proper. In Section 4.6.1. of RFC 8446, "New Session Ticket Message", we can read that Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session. Notice that there is no mention of the ALPN. We can thus expect the ticket store to be indexed by SNI, plus also some consideration about certificate explained later in the text.

There are of course lots of reason for a server to support multiple ALPN over a single port. For example, the server might support H3 and H3.1. Or it might want to provide access over port 443 for DNS over QUIC, IMAP over QUIC or other such applications. With TLS 1.3, they can do that, demux on the ALPN, and 0-RTT will work fine. But if we make the session tickets application specific, that won't work.

Which is why I think the idea of putting HTTP settings in the session ticket is ill conceived.

[kazuho]

IIUC, while it is possible to use a session ticket when the SNI is the same, you can only use early data when ALPN also matches. Quoting from RFC 8446 section 4.2.10:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are the same as those associated with the
   selected PSK:

   -  The TLS version number
   -  The selected cipher suite
   -  The selected ALPN [RFC7301] protocol, if any

[martinthomson]

I think that we can address this by saying that clients need to remember this state alongside any ticket. (And we should make it clear that the server needs to remember this also. It doesn't have to put things in the ticket, though that might make it easier for it to correctly remember.)

[mikkelfj]

I believe a comment is needed in 5.4 to at least remind the reader that other ALPN's might receive the ticket and would not be able to make use of the settings data which therefore need coordination across token consumers.

[kazuho]

@mikkelfj As I stated in #3028 (comment), it is my understanding that early-data can be used only when the ALPN matches, and therefore a QUIC stack is required to consult the application-specific data in the ticket only when the ALPN matches. Therefore I do not see any need for cross-application-protocol coordination. Am I missing something?

[mikkelfj]

@kazuho Assuming things work as you say and a client receives a token from ALPN-X, and assuming the client does not remember tokens per ALPN, then you can have another ALPN named ALPN-Y in another session receiving the token generated for ALPN-X. If the ALPN-Y endpoint does not understand how to at least ignore ALPN-X data in the token, you can get undefined behaviour.

[kazuho]

@mikkelfj

If the ALPN-Y endpoint does not understand how to at least ignore ALPN-X data in the token, you can get undefined behaviour.

I do not think so. In the case you describe, the TLS stack will not indicate to the QUIC stack that 0-RTT is acceptable because the ALPN is different. Therefore, the QUIC stack handling ALPN-Y would not use the application-protocol-specific data in the session ticket (as it is expected to be used only when early data is acceptable - that's what section 5.4 of the transport draft says). Hence no confusion.

[mikkelfj]

OK - I don't know enough about how TLS validates tokens - but if it does embed the ALPN in token validation, then the coordination I am asking for is already happening.

[mikkelfj]

So this means that 0-RTT does not work across protocols? This is unfortunate because if a client connects for HTTP and then connects for WebRTC data, it cannot use 0-RTT for WebRTC.

[kazuho]

So this means that 0-RTT does not work across protocols?

Correct. That is the restriction of TLS 1.3.

[kazuho]

So spec-wise, I think we might want to change:

"if Early Data is supported, retrieve application-controlled data from the client’s resumption ticket and enable rejecting Early Data based on that information."

to

"if Early Data is supported, and when the TLS protocol stack indicates that Early Data can be accepted, retrieve application-controlled data from the client’s resumption ticket and enable rejecting Early Data based on that information."

as well as suggesting that the application protocol-specific information is to be associated rather than stored, as pointed out by @martinthomson in #3028 (comment).

[huitema]

I am not too worried about the server side. Servers that support multiple applications can put adequate information in the token, such as for example a server release number that points to the initial condition for multiple protocols. But I am concerned about clearly spelling out the client-side requirements, and I would rather see two parallel requirements: remember the initial conditions per ALPN+SNI, and remember the ticket per SNI.

Note that we want fast rotation of tickets for privacy reasons -- use tickets at most once if possible. That works better if we don't add rigidity, such as "only reuse tickets per SNI+ALPN".

I think that resuming across multiple ALPN is a valid scenario. Kazuho points out that it may not be well supported in TLS 1.3, but we don't want to further ossify the lack of support.

Of course, none of that matters if we run all application protocols over HTTP.

[MikeBishop]

I don't think it's "not well supported," it's entirely not permitted by TLS 1.3. You can resume a session, saving crypto work, but there won't be early data on it. If TLS changes in a future version or extension, QUIC can match.

However, the most recent update to the text on how you handle stored SETTINGS does have a case for not being able to recover the SETTINGS from last time, which would seem to apply if TLS permitted early data from a non-HTTP session. You get the defaults, until you see the SETTINGS frame. The required capability could include not finding any corresponding data in the ticket.