From a38e49b3e25977f9dea8f0bc099e542f04004d5a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 14 Jul 2020 16:21:56 +1000 Subject: [PATCH 01/11] Be clearer about protections This breaks down some of the packet protection text in favour of more specific language about the protections provided. By preference, this talks about integrity protection and confidentiality protection as it relates to those packets that are protected using keys derived from TLS. For Initial packets this means avoid use of "packet protection" as much as possible (I'm sure that I have missed some of these). The same for Retry. This required some additional framing, but it wasn't too intrusive. Most of the changes are cosmetic. Closes #3887. --- draft-ietf-quic-tls.md | 75 ++++++++++++++++++++++++------------ draft-ietf-quic-transport.md | 48 +++++++++++++---------- 2 files changed, 77 insertions(+), 46 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 4185029628..15978892dd 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -895,7 +895,28 @@ keeping track of missing packet numbers. # Packet Protection {#packet-protection} As with TLS over TCP, QUIC protects packets with keys derived from the TLS -handshake, using the AEAD algorithm negotiated by TLS. +handshake, using the AEAD algorithm {{!AEAD}} negotiated by TLS. + +QUIC packets have varying protections depending on their type: + +* Version Negotiation packets have no cryptographic protection. + +* Retry packets use AEAD_AES_128_GCM to provide protection against accidental + modification or insertion by off-path adversaries; see + {{retry-integrity}}. + +* Initial packets use AEAD_AES_128_GCM with keys derived from the Destination + Connection ID field of the client Initial packet; see {{initial-secrets}}. + +* All other packets have strong cryptographic protections for confidentiality + and integrity, using keys and algorithms negotiated by TLS. + +This section describes how packet protection is applied to Handshake packets, +0-RTT packets, and packets with short headers. The same packet protection +process is applied to Initial packets. However, as it is trivial to determine +the keys, Initial packets are not considered to have confidentiality or +integrity protection. Retry packets use a fixed key and so similarly lack +confidentiality and integrity protection. ## Packet Protection Keys {#protection-keys} @@ -923,13 +944,27 @@ KDF to produce the AEAD key; the label "quic iv" is used to derive the IV; see and TLS; see {{key-diversity}}. The KDF used for initial secrets is always the HKDF-Expand-Label function from -TLS 1.3 (see {{initial-secrets}}). +TLS 1.3; see {{initial-secrets}}. ## Initial Secrets {#initial-secrets} -Initial packets are protected with a secret derived from the Destination -Connection ID field from the client's Initial packet. Specifically: +Initial packets apply the packet protection process, but use a secret derived +from the Destination Connection ID field from the client's Initial packet. + +This secret is determined by using HKDF-Extract (see Section 2.2 of +{{!HKDF=RFC5869}}) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 +and a IKM of the Destination Connection ID field. This produces an intermediate +pseudorandom key (PRK) that is used to derive two separate secrets for sending +and receiving. + +The secret used by clients to construct Initial packets uses the PRK and the +label "client in" as input to the HKDF-Expand-Label function to produce a 32 +byte secret; packets constructed by the server use the same process with the +label "server in". The hash function for HKDF when deriving initial secrets +and keys is SHA-256 {{!SHA=DOI.10.6028/NIST.FIPS.180-4}}. + +This process in pseudocode is: ~~~ initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899 @@ -944,24 +979,20 @@ server_initial_secret = HKDF-Expand-Label(initial_secret, Hash.length) ~~~ -The hash function for HKDF when deriving initial secrets and keys is SHA-256 -{{!SHA=DOI.10.6028/NIST.FIPS.180-4}}. - The connection ID used with HKDF-Expand-Label is the Destination Connection ID in the Initial packet sent by the client. This will be a randomly-selected value unless the client creates the Initial packet after receiving a Retry packet, where the Destination Connection ID is selected by the server. -The value of initial_salt is a 20 byte sequence shown in the figure in -hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value, -thus ensuring that the keys are different for each version of QUIC. This -prevents a middlebox that only recognizes one version of QUIC from seeing or -modifying the contents of packets from future versions. +Future versions of QUIC SHOULD generate a new salt value, thus ensuring that +the keys are different for each version of QUIC. This prevents a middlebox that +only recognizes one version of QUIC from seeing or modifying the contents of +packets from future versions. The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3. -The secrets used for protecting Initial packets change when a server sends a +The secrets used for constructing Initial packets change when a server sends a Retry packet to use the connection ID value selected by the server. The secrets do not change when a client changes the Destination Connection ID it uses in response to an Initial packet from the server. @@ -974,7 +1005,7 @@ Note: that the server received its packet; the client has to rely on the exchange that included the Retry packet for that property. -{{test-vectors}} contains test vectors for packet encryption. +{{test-vectors}} contains sample Initial packets. ## AEAD Usage {#aead} @@ -984,17 +1015,6 @@ used for QUIC packet protection is the AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. -Packets are protected prior to applying header protection ({{header-protect}}). -The unprotected packet header is part of the associated data (A). When removing -packet protection, an endpoint first removes the header protection. - -All QUIC packets other than Version Negotiation and Retry packets are protected -with an AEAD algorithm {{!AEAD}}. Prior to establishing a shared secret, packets -are protected with AEAD_AES_128_GCM and a key derived from the Destination -Connection ID in the client's first Initial packet (see {{initial-secrets}}). -This provides protection against off-path attackers and robustness against QUIC -version unaware middleboxes, but not against on-path attackers. - QUIC can use any of the ciphersuites defined in {{!TLS13}} with the exception of TLS_AES_128_CCM_8_SHA256. A ciphersuite MUST NOT be negotiated unless a header protection scheme is defined for the ciphersuite. This document defines a @@ -1008,6 +1028,11 @@ Note: does not support, or it would be impossible to deploy a new ciphersuite. This also applies to TLS_AES_128_CCM_8_SHA256. +When constructing packets, the AEAD function is applied prior to applying +header protection; see {{header-protect}}. The unprotected packet header is part +of the associated data (A). When processing packets, an endpoint first +removes the header protection. + The key and IV for the packet are computed as described in {{protection-keys}}. The nonce, N, is formed by combining the packet protection IV with the packet number. The 62 bits of the reconstructed QUIC packet number in network byte diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cff4ea5836..15d5f491a7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1165,10 +1165,11 @@ discarded if they indicate a different protocol version than that of the connection, or if the removal of packet protection is unsuccessful once the expected keys are available. -Invalid packets without packet protection, such as Initial, Retry, or Version -Negotiation, MAY be discarded. An endpoint MUST generate a connection error if -processing of the contents of these packets prior to discovering an error -resulted in changes to the state of a connection that cannot be reverted. +Invalid packets that lack strong integrity protection, such as Initial, Retry, +or Version Negotiation, MAY be discarded. An endpoint MUST generate a +connection error if processing of the contents of these packets prior to +discovering an error resulted in changes to the state of a connection that +cannot be reverted. ### Client Packet Handling {#client-pkt-handling} @@ -3139,30 +3140,35 @@ after a connection is established and 1-RTT keys are available; see ## Protected Packets {#packet-protected} -All QUIC packets except Version Negotiation packets use authenticated encryption -with associated data (AEAD) {{!RFC5116}} to provide confidentiality and -integrity protection. Retry packets use AEAD to provide integrity protection. -Details of packet protection are found in {{QUIC-TLS}}; this section includes an -overview of the process. - -Initial packets are protected using keys that are statically derived. This -packet protection is not effective confidentiality protection. Initial -protection only exists to ensure that the sender of the packet is on the network -path. Any entity that receives the Initial packet from a client can recover the -keys necessary to remove packet protection or to generate packets that will be +QUIC packets have different levels of cryptographic protection based on the +type of packet. Details of packet protection are found in {{QUIC-TLS}}; this +section includes an overview of the protections that are provided. + +Version Negotiation packets have no cryptographic protection; see +{{QUIC-INVARIANTS}}. + +Retry packets use an authenticated encryption with associated data (AEAD; +{{?AEAD=RFC5116}}) function to protect against accidental modification. + +Initial packets use an AEAD with keys that are statically derived. This does +not provide effective confidentiality protection. Initial protection exists to +ensure that the sender of the packet is on the network path. Any entity that +receives the Initial packet from a client can recover the keys that will allow +them to read the contents of packets or generate packets that will be successfully authenticated. All other packets are protected with keys derived from the cryptographic handshake. The type of the packet from the long header or key phase from the short header are used to identify which encryption keys are used. Packets -protected with 0-RTT and 1-RTT keys are expected to have confidentiality and -data origin authentication; the cryptographic handshake ensures that only the +protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality +and integrity protection; the cryptographic handshake ensures that only the communicating endpoints receive the corresponding keys. -The packet number field contains a packet number, which has additional -confidentiality protection that is applied after packet protection is applied; -see {{QUIC-TLS}} for details. The underlying packet number increases with each -packet sent in a given packet number space; see {{packet-numbers}} for details. +The Packet Number field that appears in some packet types contains a packet +number, which has additional confidentiality protection that is applied as part +of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The +underlying packet number increases with each packet sent in a given packet +number space; see {{packet-numbers}} for details. ## Coalescing Packets {#packet-coalesce} From 25264d07790fcb63f08d3400a9bb61aa6a4785c2 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 14 Jul 2020 16:34:44 +1000 Subject: [PATCH 02/11] First initial --- draft-ietf-quic-tls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 15978892dd..027fc8a850 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -950,7 +950,8 @@ TLS 1.3; see {{initial-secrets}}. ## Initial Secrets {#initial-secrets} Initial packets apply the packet protection process, but use a secret derived -from the Destination Connection ID field from the client's Initial packet. +from the Destination Connection ID field from the client's first Initial +packet. This secret is determined by using HKDF-Extract (see Section 2.2 of {{!HKDF=RFC5869}}) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 From 83e840eb0fdef5f972306477b8b9cc62fe355bb4 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 15 Jul 2020 08:49:04 +1000 Subject: [PATCH 03/11] first Initial Co-authored-by: Mike Bishop --- draft-ietf-quic-tls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 027fc8a850..95411cae0b 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -906,7 +906,8 @@ QUIC packets have varying protections depending on their type: {{retry-integrity}}. * Initial packets use AEAD_AES_128_GCM with keys derived from the Destination - Connection ID field of the client Initial packet; see {{initial-secrets}}. + Connection ID field of the first Initial packet sent by the client; see + {{initial-secrets}}. * All other packets have strong cryptographic protections for confidentiality and integrity, using keys and algorithms negotiated by TLS. From c78921e5d3ff5d5ea37a398eccd8afd74872e71b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 16 Jul 2020 14:04:23 +1000 Subject: [PATCH 04/11] Use text from master for this paragraph --- 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 75aaafb15d..c2b2159393 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1017,12 +1017,12 @@ used for QUIC packet protection is the AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM function is used. -QUIC can use any of the ciphersuites defined in {{!TLS13}} with the exception of -TLS_AES_128_CCM_8_SHA256. A ciphersuite MUST NOT be negotiated unless a header -protection scheme is defined for the ciphersuite. This document defines a -header protection scheme for all ciphersuites defined in {{!TLS13}} aside from -TLS_AES_128_CCM_8_SHA256. These ciphersuites have a 16-byte authentication tag -and produce an output 16 bytes larger than their input. +QUIC can use any of the cipher suites defined in {{!TLS13}} with the exception +of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be negotiated unless a +header protection scheme is defined for the cipher suite. This document defines +a header protection scheme for all cipher suites defined in {{!TLS13}} aside +from TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte +authentication tag and produce an output 16 bytes larger than their input. Note: From 1db24ca405c391ad6044260aeb196626b1c716d3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 16 Jul 2020 14:04:53 +1000 Subject: [PATCH 05/11] Trailing whitespace, gah --- 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 c2b2159393..ee39ac5a86 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1022,7 +1022,7 @@ of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be negotiated unless a header protection scheme is defined for the cipher suite. This document defines a header protection scheme for all cipher suites defined in {{!TLS13}} aside from TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte -authentication tag and produce an output 16 bytes larger than their input. +authentication tag and produce an output 16 bytes larger than their input. Note: From 05cb8f2eb7027a63f4697fccec69a18f194a405b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 20 Jul 2020 09:34:34 +1000 Subject: [PATCH 06/11] Lots of review comments These will need to be wrapped Co-authored-by: ianswett Co-authored-by: Jana Iyengar Co-authored-by: Kazuho Oku --- draft-ietf-quic-tls.md | 4 ++-- draft-ietf-quic-transport.md | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index ee39ac5a86..f052b5ac32 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -913,9 +913,9 @@ QUIC packets have varying protections depending on their type: and integrity, using keys and algorithms negotiated by TLS. This section describes how packet protection is applied to Handshake packets, -0-RTT packets, and packets with short headers. The same packet protection +0-RTT packets, and 1-RTT packets. The same packet protection process is applied to Initial packets. However, as it is trivial to determine -the keys, Initial packets are not considered to have confidentiality or +the keys used for Initial packets, these packets are not considered to have confidentiality or integrity protection. Retry packets use a fixed key and so similarly lack confidentiality and integrity protection. diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a19f3fabf5..3c4bd97161 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1177,8 +1177,8 @@ expected keys are available. Invalid packets that lack strong integrity protection, such as Initial, Retry, or Version Negotiation, MAY be discarded. An endpoint MUST generate a -connection error if processing of the contents of these packets prior to -discovering an error resulted in changes to the state of a connection that +connection error if processing the contents of these packets prior to +discovering an error resulted in changes to connection state that cannot be reverted. @@ -3165,10 +3165,10 @@ section includes an overview of the protections that are provided. Version Negotiation packets have no cryptographic protection; see {{QUIC-INVARIANTS}}. -Retry packets use an authenticated encryption with associated data (AEAD; -{{?AEAD=RFC5116}}) function to protect against accidental modification. +Retry packets use an authenticated encryption with associated data function +(AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification. -Initial packets use an AEAD with keys that are statically derived. This does +Initial packets use an AEAD with keys that are derived using a value that is visible on the wire, and therefore does not provide effective confidentiality protection. Initial protection exists to ensure that the sender of the packet is on the network path. Any entity that receives the Initial packet from a client can recover the keys that will allow @@ -3182,8 +3182,8 @@ protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality and integrity protection; the cryptographic handshake ensures that only the communicating endpoints receive the corresponding keys. -The Packet Number field that appears in some packet types contains a packet -number, which has additional confidentiality protection that is applied as part +The Packet Number field that appears in some packet types +has additional confidentiality protection that is applied as part of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The underlying packet number increases with each packet sent in a given packet number space; see {{packet-numbers}} for details. From bca2743083bca2e8a7b85abb392b85675798c8fe Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 20 Jul 2020 09:36:06 +1000 Subject: [PATCH 07/11] wrap --- draft-ietf-quic-tls.md | 6 +++--- draft-ietf-quic-transport.md | 22 +++++++++++----------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index f052b5ac32..99219a5f5f 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -913,9 +913,9 @@ QUIC packets have varying protections depending on their type: and integrity, using keys and algorithms negotiated by TLS. This section describes how packet protection is applied to Handshake packets, -0-RTT packets, and 1-RTT packets. The same packet protection -process is applied to Initial packets. However, as it is trivial to determine -the keys used for Initial packets, these packets are not considered to have confidentiality or +0-RTT packets, and 1-RTT packets. The same packet protection process is applied +to Initial packets. However, as it is trivial to determine the keys used for +Initial packets, these packets are not considered to have confidentiality or integrity protection. Retry packets use a fixed key and so similarly lack confidentiality and integrity protection. diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3c4bd97161..f3b6c78dd7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3168,12 +3168,12 @@ Version Negotiation packets have no cryptographic protection; see Retry packets use an authenticated encryption with associated data function (AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification. -Initial packets use an AEAD with keys that are derived using a value that is visible on the wire, and therefore does -not provide effective confidentiality protection. Initial protection exists to -ensure that the sender of the packet is on the network path. Any entity that -receives the Initial packet from a client can recover the keys that will allow -them to read the contents of packets or generate packets that will be -successfully authenticated. +Initial packets use an AEAD with keys that are derived using a value that is +visible on the wire, and therefore does not provide effective confidentiality +protection. Initial protection exists to ensure that the sender of the packet is +on the network path. Any entity that receives the Initial packet from a client +can recover the keys that will allow them to read the contents of packets or +generate packets that will be successfully authenticated. All other packets are protected with keys derived from the cryptographic handshake. The type of the packet from the long header or key phase from the @@ -3182,11 +3182,11 @@ protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality and integrity protection; the cryptographic handshake ensures that only the communicating endpoints receive the corresponding keys. -The Packet Number field that appears in some packet types -has additional confidentiality protection that is applied as part -of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The -underlying packet number increases with each packet sent in a given packet -number space; see {{packet-numbers}} for details. +The Packet Number field that appears in some packet types has alternative +confidentiality protection that is applied as part of header protection; see +Section 5.4 of {{QUIC-TLS}} for details. The underlying packet number increases +with each packet sent in a given packet number space; see {{packet-numbers}} for +details. ## Coalescing Packets {#packet-coalesce} From 92d1701ac1e5b1554dc1df4abf0c7af3a5b0d403 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Jul 2020 19:48:47 +1000 Subject: [PATCH 08/11] Moor sugestions Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 2 +- draft-ietf-quic-transport.md | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 99219a5f5f..afde50ef73 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -988,7 +988,7 @@ packet, where the Destination Connection ID is selected by the server. Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC. This prevents a middlebox that -only recognizes one version of QUIC from seeing or modifying the contents of +recognizes only one version of QUIC from seeing or modifying the contents of packets from future versions. The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f3b6c78dd7..918f468cad 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3171,9 +3171,10 @@ Retry packets use an authenticated encryption with associated data function Initial packets use an AEAD with keys that are derived using a value that is visible on the wire, and therefore does not provide effective confidentiality protection. Initial protection exists to ensure that the sender of the packet is -on the network path. Any entity that receives the Initial packet from a client -can recover the keys that will allow them to read the contents of packets or -generate packets that will be successfully authenticated. +on the network path. Any entity that receives an Initial packet from a client +can recover the keys that will allow them to both read the contents of the packet +and generate Initial packets that will be successfully authenticated at either +endpoint. All other packets are protected with keys derived from the cryptographic handshake. The type of the packet from the long header or key phase from the From 00d90fccb3fb8dfb3e831198629a63b0399052ad Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 20 Jul 2020 17:59:13 +1000 Subject: [PATCH 09/11] Some more rearrangement --- draft-ietf-quic-transport.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 918f468cad..c06809f501 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3177,11 +3177,9 @@ and generate Initial packets that will be successfully authenticated at either endpoint. All other packets are protected with keys derived from the cryptographic -handshake. The type of the packet from the long header or key phase from the -short header are used to identify which encryption keys are used. Packets -protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality -and integrity protection; the cryptographic handshake ensures that only the -communicating endpoints receive the corresponding keys. +handshake. The cryptographic handshake ensures that only the communicating +endpoints receive the corresponding keys. Packets protected with 0-RTT and +1-RTT keys are expected to have strong confidentiality and integrity protection. The Packet Number field that appears in some packet types has alternative confidentiality protection that is applied as part of header protection; see From 645d6f8be9824db6909f2a02131c21a690a30809 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 20 Jul 2020 18:00:24 +1000 Subject: [PATCH 10/11] Cleaner --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c06809f501..856da6383b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3177,9 +3177,10 @@ and generate Initial packets that will be successfully authenticated at either endpoint. All other packets are protected with keys derived from the cryptographic -handshake. The cryptographic handshake ensures that only the communicating -endpoints receive the corresponding keys. Packets protected with 0-RTT and -1-RTT keys are expected to have strong confidentiality and integrity protection. +handshake. The cryptographic handshake ensures that only the communicating +endpoints receive the corresponding keys for Handshake, 0-RTT, and 1-RTT +packets. Packets protected with 0-RTT and 1-RTT keys have strong +confidentiality and integrity protection. The Packet Number field that appears in some packet types has alternative confidentiality protection that is applied as part of header protection; see From 7f190d7ec7885c46bc0a4e40a3535870af006b6d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 21 Jul 2020 19:49:58 +1000 Subject: [PATCH 11/11] Split sentence; reword --- draft-ietf-quic-transport.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 856da6383b..697267919d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3168,13 +3168,13 @@ Version Negotiation packets have no cryptographic protection; see Retry packets use an authenticated encryption with associated data function (AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification. -Initial packets use an AEAD with keys that are derived using a value that is -visible on the wire, and therefore does not provide effective confidentiality -protection. Initial protection exists to ensure that the sender of the packet is -on the network path. Any entity that receives an Initial packet from a client -can recover the keys that will allow them to both read the contents of the packet -and generate Initial packets that will be successfully authenticated at either -endpoint. +Initial packets use an AEAD, the keys for which are derived using a value that +is visible on the wire. Initial packets therefore do not have effective +confidentiality protection. Initial protection exists to ensure that the sender +of the packet is on the network path. Any entity that receives an Initial packet +from a client can recover the keys that will allow them to both read the +contents of the packet and generate Initial packets that will be successfully +authenticated at either endpoint. All other packets are protected with keys derived from the cryptographic handshake. The cryptographic handshake ensures that only the communicating