Original text:
4.1. As shown in schematic, the interface from QUIC to TLS consists of <del> three primary functions: </del>  Sending and receiving handshake messages  Rekeying (both transmit and receive) Handshake state updates 4.7.  In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of TLS13) can be used to correct a client's incorrect KeyShare extension as well as for a stateless round-trip check.  From the perspective of instead use the Retry feature (see Section 8.1 of QUIC-TRANSPORT). HelloRetryRequest is still used to request key shares. <del> 4.8. </del>  If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13. The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <del> 4.9. </del>  After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded.  This occurs several and retransmissions of data in CRYPTO frames are sent at a previous encryption level.  These packets MAY also include PADDING frames. <del> 4.9.1. </del>  Packets protected with Initial secrets (initial-secrets) are not authenticated, meaning that an attacker could spoof packets with the This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets. <del> 4.9.2. </del>  An endpoint MUST NOT discard its handshake keys until the TLS handshake is confirmed (handshake-confirmed).  An endpoint SHOULD eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged. <del> 4.9.3. </del>  0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet

Reviewer comments:
This PR describes how a TLS stack needs to cooperate with a QUIC stack when making the decision whether or not to accept early data. The purpose of this change is so that implementors working on the TLS layer of QUIC are aware that other layers impact decisions traditionally made at the TLS layer.
This could potentially also update the diagram at URL (adding a line for the server between "Handshake Received" and "Get Handshake").
Do I need to take any action to get this PR merged? (Should this be labeled editorial?)
I think that this is borderline editorial, as you more or less have to do this. It does change the API, which is enough of a change that it's worth having an issue. I'll open an issue and ask the chairs to call consensus.
I opened a related issue -- . The conversation above focuses on the server, but what about ticket handling by the client? Current ticket stores are per SNI. Should they become per-SNI + per-ALPN?
Does it even make sense to assume ALPN is always present in multiplexing protocols? An endpoint could have multiple active protocols on the same connection even if that is not supported by any protocol we currently know of.
ALPN is required by QUIC.
This is borderline off topic - but if ALPN is visible and firewalls use this to block traffic, endpoints might want to hide the ALPN. I suppose there is some ongoing work on ALPN encryption?
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.
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:
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.)
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.
NAME As I stated in URL, 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?
NAME 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.
NAME 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.
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.
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.
Correct. That is the restriction of TLS 1.3.
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 NAME in URL
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.
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.
PR describes a new piece of the interface between a QUIC and TLS implementation as it relates to 0-RTT. That's not really new - you had to do this to get 0-RTT working - but it is enough new text that it's worth having this pass under the collective noses of the working group. NAME has produced text, which I think is good, but we should run the process. Chairs, my suggestion is that we mark this "design" and run a consensus call.
Closed with .
The text looks like a nice improvement :+1: :+1:. LGTM modulo the point below.

Revised text:
4.1. As shown in schematic, the interface from QUIC to TLS consists of  <ins> four primary functions: </ins> Sending and receiving handshake messages <ins> Processing stored transport and application state from a resumed session and determining if it is valid to accept early data </ins> Rekeying (both transmit and receive) Handshake state updates 4.7. <ins> When a server receives a ClientHello with the "early_data" extension, it has to decide whether to accept or reject early data from the client.  Some of this decision is made by the TLS stack (e.g., checking that the cipher suite being resumed was included in the ClientHello; see Section 4.2.10 of TLS13).  Even when the TLS stack has no reason to reject early data, the QUIC stack or the application protocol using QUIC might reject early data because the configuration of the transport or application associated with the resumed session is not compatible with the server's current configuration. QUIC requires additional transport state to be associated with a 0-RTT session ticket.  One common way to implement this is using stateless session tickets and storing this state in the session ticket.  Application protocols that use QUIC might have similar requirements regarding associating or storing state.  This associated state is used for deciding whether early data must be rejected.  For example, HTTP/3 (QUIC-HTTP) settings determine how early data from the client is interpreted.  Other applications using QUIC could have different requirements for determining whether to accept or reject early data. 4.8. </ins> In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of TLS13) can be used to correct a client's incorrect KeyShare extension as well as for a stateless round-trip check.  From the perspective of instead use the Retry feature (see Section 8.1 of QUIC-TRANSPORT). HelloRetryRequest is still used to request key shares.  <ins> 4.9. </ins> If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13. The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level.  <ins> 4.10. </ins> After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded.  This occurs several and retransmissions of data in CRYPTO frames are sent at a previous encryption level.  These packets MAY also include PADDING frames.  <ins> 4.10.1. </ins> Packets protected with Initial secrets (initial-secrets) are not authenticated, meaning that an attacker could spoof packets with the This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets.  <ins> 4.10.2. </ins> An endpoint MUST NOT discard its handshake keys until the TLS handshake is confirmed (handshake-confirmed).  An endpoint SHOULD eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged.  <ins> 4.10.3. </ins> 0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet