From c9e297403c30d34ccc3e278d6f0546f416f73543 Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 25 Sep 2018 18:51:19 -0700 Subject: [PATCH 1/5] Minor nits Added a few explicit statements about how TCP-TLS and QUIC-TLS differ. Synced with the transport draft about which frames are allowed in which contexts. --- draft-ietf-quic-tls.md | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 2b8fccf39f..02a2a52b86 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -161,6 +161,9 @@ series of typed TLS records. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP) which provides sequencing and guaranteed delivery. +Note that Change Cipher Spec records, optional in TLS over TCP, have no +encoding for TLS over QUIC. + The TLS authenticated key exchange occurs between two entities: client and server. The client initiates the exchange and the server responds. If the key exchange completes successfully, both client and server will agree on a secret. @@ -259,8 +262,8 @@ QUIC also relies on TLS 1.3 for authentication and negotiation of parameters that are critical to security and performance. Rather than a strict layering, these two protocols are co-dependent: QUIC uses -the TLS handshake; TLS uses the reliability and ordered delivery provided by -QUIC streams. +the TLS handshake; TLS uses the reliability, ordered delivery, and record +layer provided by QUIC. At a high level, there are two main interactions between the TLS and QUIC components: @@ -298,7 +301,6 @@ Unlike TLS over TCP, QUIC applications which want to send data do not send it through TLS "application_data" records. Rather, they send it as QUIC STREAM frames which are then carried in QUIC packets. - # Carrying TLS Messages {#carrying-tls} QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a @@ -320,14 +322,17 @@ Each encryption level has a specific list of frames which may appear in it. The rules here generalize those of TLS, in that frames associated with establishing the connection can usually appear at any encryption level, whereas those associated with transferring data can only appear in the 0-RTT and 1-RTT -encryption levels +encryption levels. - CRYPTO frames MAY appear in packets of any encryption level except 0-RTT. -- CONNECTION_CLOSE and APPLICATION_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. + +- APPLICATION_CLOSE MAY appear in packets of any encyrpto level other than + Initial and 0-RTT. -- PADDING and PING frames MAY appear in packets of any encryption level. +- PADDING 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 packet number space. @@ -387,6 +392,10 @@ peer in CRYPTO frames. When TLS provides handshake octets to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. +Unlike its operations with TCP, the TLS bytestream is never separately +encrypted and decrypted. This operation only occurs on the QUIC packet as a +whole. + When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: From 27b95f7181f42a39a29a0638c942d81556bc33ab Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 25 Sep 2018 18:55:04 -0700 Subject: [PATCH 2/5] typo --- 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 02a2a52b86..e538cfc67a 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -329,7 +329,7 @@ encryption levels. - CONNECTION_CLOSE MAY appear in packets of any encryption level other than 0-RTT. -- APPLICATION_CLOSE MAY appear in packets of any encyrpto level other than +- APPLICATION_CLOSE MAY appear in packets of any encryption level other than Initial and 0-RTT. - PADDING frames MAY appear in packets of any encryption level. From 090131d1bce5c8bbf2363b23775c4129514c5eb3 Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 25 Sep 2018 18:59:30 -0700 Subject: [PATCH 3/5] eliminate whitespace --- 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 e538cfc67a..13b35c5dd6 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -328,7 +328,7 @@ encryption levels. - CONNECTION_CLOSE MAY appear in packets of any encryption level other than 0-RTT. - + - APPLICATION_CLOSE MAY appear in packets of any encryption level other than Initial and 0-RTT. From ff5601506f8c1837fb61d2e0a8fc9f079125a971 Mon Sep 17 00:00:00 2001 From: martinduke Date: Wed, 26 Sep 2018 14:19:30 -0700 Subject: [PATCH 4/5] Addressed MT's issues --- draft-ietf-quic-tls.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 13b35c5dd6..5b8cd1a2a4 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -161,8 +161,7 @@ series of typed TLS records. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP) which provides sequencing and guaranteed delivery. -Note that Change Cipher Spec records, optional in TLS over TCP, have no -encoding for TLS over QUIC. +Change Cipher Spec records cannot be sent in QUIC. The TLS authenticated key exchange occurs between two entities: client and server. The client initiates the exchange and the server responds. If the key @@ -322,7 +321,7 @@ Each encryption level has a specific list of frames which may appear in it. The rules here generalize those of TLS, in that frames associated with establishing the connection can usually appear at any encryption level, whereas those associated with transferring data can only appear in the 0-RTT and 1-RTT -encryption levels. +encryption levels: - CRYPTO frames MAY appear in packets of any encryption level except 0-RTT. @@ -392,9 +391,10 @@ peer in CRYPTO frames. When TLS provides handshake octets to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. -Unlike its operations with TCP, the TLS bytestream is never separately -encrypted and decrypted. This operation only occurs on the QUIC packet as a -whole. +QUIC takes the unprotected content of TLS handshake records as the content of +CRYPTO frames. Encapsulation of these messages in protected TLS records does not +happen. QUIC assembles CRYPTO frames into QUIC packets, which are protected +using QUIC packet protection. When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: From 6d34304a88f7658684a35db9c3ad5d33dbd1ba2a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 26 Sep 2018 14:28:34 -0700 Subject: [PATCH 5/5] Small reword --- draft-ietf-quic-tls.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 5b8cd1a2a4..eb1e91e05d 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -392,9 +392,9 @@ appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. QUIC takes the unprotected content of TLS handshake records as the content of -CRYPTO frames. Encapsulation of these messages in protected TLS records does not -happen. QUIC assembles CRYPTO frames into QUIC packets, which are protected -using QUIC packet protection. +CRYPTO frames. TLS record protection is not used by QUIC. QUIC assembles +CRYPTO frames into QUIC packets, which are protected using QUIC packet +protection. When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: