Change:
the change.  An endpoint that notices a changed Key Phase bit updates keys and decrypts the packet that contains the changed value. <del> This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type 0x10a, equivalent to a fatal TLS alert of unexpected_message (see tls- errors). </del> <ins> This mechanism replaces the key update mechanism of TLS, which relies on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message in a 1-RTT packet as a connection error of type 0x10a, equivalent to a fatal TLS alert of unexpected_message; see tls-errors. </ins> ex-key-update shows a key update process, where the initial set of keys used (identified with @M) are replaced by updated keys

Discussion:
QUIC-TLS defines some "adjustments"(URL) to TLS 1.3. As they are adjustments, we are updating TLS only when necessary. However, discussion in seems to have revealed one corner case that is ambiguous. This PR addresses that problem. To be specific, TLS 1.3 defines the necessary action when an endpoint receives KeyUpdate message in epochs other than 1-RTT. However, current statement in QUIC-TLS can be read as if it is updating that. This PR makes it clear that the "adjustment" applies to only when the use of KeyUpdate is permitted by TLS 1.3 but not in QUIC-TLS.
NAME now supports an error case of TLS KeyUpdate in 1-RTT. Based on experiments with , it appeared that TLS stack might be freed already when any CRYPTOs including KeyUpdate in 1-RTT are received. So, we should also allow in this case.
I don't see any reason to specifically allow PROTOCOLVIOLATION here (it's allowed as a fallback for any error code anyway), as it's possible for a QUIC stack to generate an error code in the CRYPTOERROR space, even if the TLS stack has already been shut down.
NAME It's possible but it's not reasonable because QUIC stack needs to parse TLS messages. BTW, where can I find the fallback rule?
NAME A QUIC stack that discards the TLS state post-handshake is committing to handle TLS messages by itself. Therefore, it has to handle them correctly. In practice, such QUIC stack running as clients have to handle NewSessionTicket messages correctly; therefore they need to be capable of parsing TLS messages. Such stacks running as servers can respond with unexpected_message alert for any post-handshake message that they receive, because in RFC 8446 there isn't a case where a client unilaterally sends a post-handshake message with the only exception being KeyUpdate. It is defined at URL
Thanks. I'm fine with this rule. So, I withdraw my suggestion.
Sec 4.5 says: This does not specify how a server MUST do if in Initial/Handshake/1-RTT is received. I think that a server MUST send the TLS alert of .
Sounds reasonable to me.

I'm not sure if we need to change, or if the proposed change is reasonable. Doesn't RFC 8446 already state that the receiver MUST error-close the connection when it receives EndOfEarlyData in other epochs? Assuming that that is the case, I think that the current text is correct, because the section talks about "QUIC-Specific Adjustments to the TLS Handshake."
The draft also says: What is the difference between KeyUpdate and EndOfEarlyData?
NAME I'd argue that the only way to interpret that text is that the KeyUpdate message cannot be used even when permitted by TLS 1.3 (i.e. in 1-RTT packets). The italic part is implied, rather than explicitly stated like the case for EndOfEarlyData. If there's ambiguity, we can try to be explicit. I do not have a strong opinion on if we need to. PS. To be clear, what I am saying is that the behavior for the following cases are defined by TLS 1.3, and that we should not re-specify them: use of EndOfEarlyData in epoch other than 0-RTT use of KeyUpdate in epoch other than 1-RTT
To let readers interpret the text as "cannot be used", we should simply use "cannot be used". If "MUST NOT" is used, the handling should be specified.
I do not think anything should change personally.
FWIW I've filed that does not do anything regarding the original issue, but makes changes to the specification regarding KeyUpdate to clarify that it is not intended to respecify how TLS rejects that message during handshake.
Marking as editoiral. If I'm wrong please speak up.
This LGTM. I would consider this an editorial change.