From 0acc8f8b945ffc6199492f12fa6d0c5059101175 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 26 Jun 2018 11:38:21 +1000 Subject: [PATCH 1/5] Use CONNECTION_CLOSE rather than CRYPTO_CLOSE --- draft-ietf-quic-tls.md | 18 ++++--- draft-ietf-quic-transport.md | 94 +++++++++++++++--------------------- 2 files changed, 50 insertions(+), 62 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 39e51eee12..898056a8f6 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -329,8 +329,8 @@ encryption level, whereas those associated with transferring data can only appear in the 0-RTT and 1-RTT encryption levels - CRYPTO_HS frames MAY appear in packets of any encryption level. -- CONNECTION_CLOSE and CRYPTO_CLOSE MAY appear in packets of any - encryption level other than 0-RTT. +- CONNECTION_CLOSE MAY appear in packets of any encryption level other than + 0-RTT. - PADDING and PING frames MAY appear in packets of any encryption level. - ACK frames MAY appear in packets of any encryption level other than 0-RTT, but can only acknowledge packets which appeared in that @@ -602,10 +602,16 @@ HelloRetryRequest is still used for incorrect key shares. ## TLS Errors -If TLS experiences an error, it MUST generate an appropriate alert -as defined in {{TLS13}}; Section 6) and then provide it to QUIC, -which sends the alert in a CRYPTO_CLOSE frame. All such alerts are -"fatal" (see {{TLS13}}, Section 6.2. +If TLS experiences an error, it generates an appropriate alert as defined in +Section 6 of {{TLS13}}. + +A TLS alert is turned into a QUIC connection error by converting the alert +description into a QUIC error code. The alert description is added to 0x200 to +produce a QUIC error code from the range reserved for CRYPTO_ERROR. The +resulting value is sent in a QUIC CONNECTION_CLOSE frame. + +The alert level of all TLS alerts is "fatal", a TLS stack does not generate +alerts at the "warning" level. # QUIC Packet Protection {#packet-protection} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2f94ba5cb5..360f907222 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -755,8 +755,8 @@ addresses can be verified through an address validation token any message from the client encrypted using the Handshake keys. The payload of this packet contains CRYPTO_HS frames and could contain PADDING, -or ACK frames. Handshake packets MAY contain -CRYPTO_CLOSE or CONNECTION_CLOSE frames if the handshake is unsuccessful. +or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE frames if the +handshake is unsuccessful. ## Protected Packets {#packet-protected} @@ -1032,7 +1032,6 @@ explained in more detail as they are referenced later in the document. | 0x0f | PATH_RESPONSE | {{frame-path-response}} | | 0x10 - 0x17 | STREAM | {{frame-stream}} | | 0x18 | CRYPTO_HS | {{frame-crypto}} | -| 0x19 | CRYPTO_CLOSE | {{frame-crypto-close}} | | 0x20 | NEW_TOKEN | {{frame-new-token}} | {: #frame-types title="Frame Types"} @@ -2135,7 +2134,7 @@ These states SHOULD persist for three times the current Retransmission Timeout An endpoint enters a closing period after initiating an immediate close ({{immediate-close}}). While closing, an endpoint MUST NOT send packets unless -they contain a CONNECTION_CLOSE, CRYPTO_CLOSE, or APPLICATION_CLOSE frame (see +they contain a CONNECTION_CLOSE or APPLICATION_CLOSE frame (see {{immediate-close}} for details). In the closing state, only a packet containing a closing frame can be sent. An @@ -2200,10 +2199,9 @@ before the packet is received. ### Immediate Close -An endpoint sends a closing frame, (CONNECTION_CLOSE, CRYPTO_CLOSE or -APPLICATION_CLOSE) to terminate the connection immediately. Any -closing frame causes all streams to immediately become closed; open -streams can be assumed to be implicitly reset. +An endpoint sends a closing frame, (CONNECTION_CLOSE or APPLICATION_CLOSE) to +terminate the connection immediately. Any closing frame causes all streams to +immediately become closed; open streams can be assumed to be implicitly reset. After sending a closing frame, endpoints immediately enter the closing state. During the closing period, an endpoint that sends a closing frame SHOULD respond @@ -2320,8 +2318,7 @@ Reset Token. A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a -CONNECTION_CLOSE, CRYPTO_CLOSE, or APPLICATION_CLOSE frame if it has -sufficient state to do so. +CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so. This stateless reset design is specific to QUIC version 1. An endpoint that supports multiple versions of QUIC needs to generate a stateless reset that will @@ -3258,20 +3255,6 @@ stream per encryption level. The stream does not have an explicit end, so CRYPTO_HS frames do not have a FIN bit. -## CRYPTO_CLOSE Frame {#frame-crypto-close} - -The CRYPTO_CLOSE frame (type=0x20) is used to indicate connection failures -caused by the crypto handshake. It uses the same format as the -CONNECTION_CLOSE frame ({{frame-connection-close}}), except that the -error codes are specific to the crypto protocol in use. For TLS 1.3, -the error code is simply the one-byte TLS alert number left-padded -with zeroes. - - -Other than the error code space, the format and semantics of the -CRYPTO_CLOSE frame are identical to the CONNECTION_CLOSE frame. - - # Packetization and Reliability {#packetization} A sender bundles one or more frames in a QUIC packet (see {{frames}}). @@ -3343,9 +3326,9 @@ containing that information is acknowledged. STOP_SENDING frame, is sent until the receive stream enters either a "Data Recvd" or "Reset Recvd" state, see {{solicited-state-transitions}}. -* Connection close signals, including those that use CONNECTION_CLOSE, - CRYPTO_CLOSE, and APPLICATION_CLOSE frames, are not sent again when - packet loss is detected, but as described in {{termination}}. +* Connection close signals, including those that use CONNECTION_CLOSE and + APPLICATION_CLOSE frames, are not sent again when packet loss is detected, but + as described in {{termination}}. * The current connection maximum data is sent in MAX_DATA frames. An updated value is sent in a MAX_DATA frame if the packet containing the most recently @@ -4150,22 +4133,19 @@ The most appropriate error code ({{error-codes}}) SHOULD be included in the frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used. -A stateless reset ({{stateless-reset}}) is not suitable for any error -that can be signaled with a CONNECTION_CLOSE, CRYPTO_CLOSE, -APPLICATION_CLOSE, or RST_STREAM frame. A stateless reset MUST NOT be -used by an endpoint that has the state necessary to send a frame on -the connection. +A stateless reset ({{stateless-reset}}) is not suitable for any error that can +be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame. A +stateless reset MUST NOT be used by an endpoint that has the state necessary to +send a frame on the connection. ## Connection Errors -Errors that result in the connection being unusable, such as an -obvious violation of protocol semantics or corruption of state that -affects an entire connection, MUST be signaled using a -CONNECTION_CLOSE, CRYPTO_CLOSE, or APPLICATION_CLOSE frame -({{frame-connection-close}}, {{frame-crypto-close}}, -{{frame-application-close}}). An endpoint MAY close the connection in -this manner even if the error only affects a single stream. +Errors that result in the connection being unusable, such as an obvious +violation of protocol semantics or corruption of state that affects an entire +connection, MUST be signaled using a CONNECTION_CLOSE or APPLICATION_CLOSE frame +({{frame-connection-close}}, {{frame-application-close}}). An endpoint MAY close +the connection in this manner even if the error only affects a single stream. Application protocols can signal application-specific protocol errors using the APPLICATION_CLOSE frame. Errors that are specific to the @@ -4173,22 +4153,20 @@ transport, including all those described in this document, are carried in a CONNECTION_CLOSE frame. Other than the type of error code they carry, these frames are identical in format and semantics. -A CONNECTION_CLOSE, CRYPTO_CLOSE, or APPLICATION_CLOSE frame could be -sent in a packet that is lost. An endpoint SHOULD be prepared to -retransmit a packet containing either frame type if it receives more -packets on a terminated connection. Limiting the number of -retransmissions and the time over which this final packet is sent +A CONNECTION_CLOSE, or APPLICATION_CLOSE frame could be sent in a packet that is +lost. An endpoint SHOULD be prepared to retransmit a packet containing either +frame type if it receives more packets on a terminated connection. Limiting the +number of retransmissions and the time over which this final packet is sent limits the effort expended on terminated connections. -An endpoint that chooses not to retransmit packets containing -CONNECTION_CLOSE, CRYPTO_CLOSE, or APPLICATION_CLOSE risks a peer -missing the first such packet. The only mechanism available to an -endpoint that continues to receive data for a terminated connection is -to use the stateless reset process ({{stateless-reset}}). +An endpoint that chooses not to retransmit packets containing CONNECTION_CLOSE +or APPLICATION_CLOSE risks a peer missing the first such packet. The only +mechanism available to an endpoint that continues to receive data for a +terminated connection is to use the stateless reset process +({{stateless-reset}}). -An endpoint that receives an invalid CONNECTION_CLOSE, CRYPTO_CLOSE, -or APPLICATION_CLOSE frame MUST NOT signal the existence of the error -to its peer. +An endpoint that receives an invalid CONNECTION_CLOSE or APPLICATION_CLOSE frame +MUST NOT signal the existence of the error to its peer. ## Stream Errors @@ -4286,9 +4264,14 @@ FRAME_ERROR (0x1XX): included as the last octet of the error code. For example, an error in a MAX_STREAM_ID frame would be indicated with the code (0x106). -Codes for errors occuring when TLS is used for the crypto handshake are defined -in Section 11 of {{QUIC-TLS}}. See {{iana-error-codes}} for details of -registering new error codes. +CRYPTO_ERROR (0x2XX): + +: The cryptographic handshake failed. A range of 256 values is reserved for + carrying error codes specific to the cryptographic handshake that is used. + Codes for errors occuring when TLS is used for the crypto handshake are + defined in Section 11 of {{QUIC-TLS}}. + +See {{iana-error-codes}} for details of registering new error codes. ## Application Protocol Error Codes {#app-error-codes} @@ -4563,7 +4546,6 @@ Issue and pull request numbers are listed with a leading octothorp. - Enable server to transition connections to a preferred address (#560,#1251). - Moved the cryptographic handshake off stream 0 and into CRYPTO_HS frames. -- CRYPTO_HS, and CRYPTO_CLOSE frames - Move stateless retry to the QUIC layer. - Added token fields to Initial packet header. - Added NEW_TOKEN frame. From 9b80c45f58b43ede57b9876e21df30dfa963f49b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 26 Jun 2018 15:01:11 +1000 Subject: [PATCH 2/5] one-octet description; MUST NOT warning alert --- draft-ietf-quic-tls.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 898056a8f6..dde999e40c 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -605,12 +605,12 @@ HelloRetryRequest is still used for incorrect key shares. If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of {{TLS13}}. -A TLS alert is turned into a QUIC connection error by converting the alert -description into a QUIC error code. The alert description is added to 0x200 to -produce a QUIC error code from the range reserved for CRYPTO_ERROR. The -resulting value is sent in a QUIC CONNECTION_CLOSE frame. +A TLS alert is turned into a QUIC connection error by converting the one-octet +alert description into a QUIC error code. The alert description is added to +0x200 to produce a QUIC error code from the range reserved for CRYPTO_ERROR. +The resulting value is sent in a QUIC CONNECTION_CLOSE frame. -The alert level of all TLS alerts is "fatal", a TLS stack does not generate +The alert level of all TLS alerts is "fatal", a TLS stack MUST NOT generate alerts at the "warning" level. From a77b0669f52aaa155dc6fb15f97d3aaf0237a8bf Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 27 Jun 2018 08:16:01 +1000 Subject: [PATCH 3/5] Typos, renumber --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 360f907222..73564632be 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -578,7 +578,7 @@ Token Length: Token: : An optional token blob previously received in either a Retry packet or -NEW_TOKEN frame. + NEW_TOKEN frame. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. In addition to @@ -649,7 +649,7 @@ Note: : The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received -the token in a previous connection using the NEW_TOKEN message, +the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is discarded. @@ -1032,7 +1032,7 @@ explained in more detail as they are referenced later in the document. | 0x0f | PATH_RESPONSE | {{frame-path-response}} | | 0x10 - 0x17 | STREAM | {{frame-stream}} | | 0x18 | CRYPTO_HS | {{frame-crypto}} | -| 0x20 | NEW_TOKEN | {{frame-new-token}} | +| 0x19 | NEW_TOKEN | {{frame-new-token}} | {: #frame-types title="Frame Types"} All QUIC frames are idempotent. That is, a valid frame does not cause @@ -3090,7 +3090,7 @@ a connection error of type UNSOLICITED_PATH_RESPONSE. ## NEW_TOKEN frame {#frame-new-token} -A server sends a NEW_TOKEN frame (type=0x21) to provide the client a token to +A server sends a NEW_TOKEN frame (type=0x19) to provide the client a token to send in a the header of an Initial packet for a future connection. The NEW_TOKEN frame is as follows: @@ -4153,7 +4153,7 @@ transport, including all those described in this document, are carried in a CONNECTION_CLOSE frame. Other than the type of error code they carry, these frames are identical in format and semantics. -A CONNECTION_CLOSE, or APPLICATION_CLOSE frame could be sent in a packet that is +A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is lost. An endpoint SHOULD be prepared to retransmit a packet containing either frame type if it receives more packets on a terminated connection. Limiting the number of retransmissions and the time over which this final packet is sent From d7683479e2bdde11a8763e1964916937e2f33063 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 27 Jun 2018 08:17:23 +1000 Subject: [PATCH 4/5] commas --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 73564632be..1aa2aa77c0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2199,7 +2199,7 @@ before the packet is received. ### Immediate Close -An endpoint sends a closing frame, (CONNECTION_CLOSE or APPLICATION_CLOSE) to +An endpoint sends a closing frame (CONNECTION_CLOSE or APPLICATION_CLOSE) to terminate the connection immediately. Any closing frame causes all streams to immediately become closed; open streams can be assumed to be implicitly reset. From d4ec8a52378b5b2862bb9fca3e48a7305749e06e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 27 Jun 2018 09:05:00 +1000 Subject: [PATCH 5/5] comma splice --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index dde999e40c..87f9e4d319 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -610,7 +610,7 @@ alert description into a QUIC error code. The alert description is added to 0x200 to produce a QUIC error code from the range reserved for CRYPTO_ERROR. The resulting value is sent in a QUIC CONNECTION_CLOSE frame. -The alert level of all TLS alerts is "fatal", a TLS stack MUST NOT generate +The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level.