Draft: draft-ietf-quic-tls

Commentary: QUIC - TLS defines some " adjustments " ( ) 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 . 
 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 do n'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 . 
 It 's possible but it 's not reasonable because QUIC stack needs to parse TLS messages . BTW , where can I find the fallback rule ? 
 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 is n't a case where a client unilaterally sends a post - handshake message with the only exception being KeyUpdate . It is defined at 
 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 . Does n'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 ? 
 I 'd argue that the only way to interpret that text is that the KeyUpdate message can not 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 " can not be used " , we should simply use " can not 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 .
Paragraph (version A):
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).
Paragraph (version B):
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.