From b3bb4638d5678485cc25800d647b9387f3b162ec Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Thu, 3 May 2018 14:12:49 +0200 Subject: [PATCH 1/9] First pass at varint packet numbers --- draft-ietf-quic-tls.md | 7 +++++ draft-ietf-quic-transport.md | 58 +++++++++++++++++++----------------- 2 files changed, 38 insertions(+), 27 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 7b69f43d8e..7b53db015b 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -960,6 +960,13 @@ To ensure that this process does not sample the packet number, packet number protection algorithms MUST NOT sample more ciphertext than the minimum expansion of the corresponding AEAD. +Packet number protection is applied to the packet number encoded as described +in Section 4.8 of {{QUIC-TRANSPORT}}. Since the length of the packet number is +stored in the encoded packet number, it is necessary to decrypt the maximum +length (4 octets) when removing packet number protection. The final 2 or 3 +octets of the plaintext packet number can then be discarded based on the +packet number length encoded in the first octet, as appropriate. + Before a TLS ciphersuite can be used with QUIC, a packet protection algorithm MUST be specifed for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2aa1d07160..3a62e290fe 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -386,7 +386,7 @@ See {{packet-coalesce}} for more details. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ -|0|K|1|1|0|R|T T| +|0|K|1|1|0|R R R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Connection ID (0..144) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -439,12 +439,8 @@ Google QUIC Demultipexing Bit: Reserved: -: The sixth bit (0x4) of octet 0 is reserved for experimentation. - -Short Packet Type: - -: The remaining 2 bits of octet 0 include one of 4 packet types. - {{short-packet-types}} lists the types that are defined for short packets. +: The sixth, seventh, and eighth bits (0x7) of octet 0 are reserved for +experimentation. Destination Connection ID: @@ -453,10 +449,10 @@ Destination Connection ID: Packet Number: -: The length of the packet number field depends on the packet type. This field - can be 1, 2 or 4 octets long depending on the short packet type. Packet - numbers are not encrypted as part of packet protection, but instead have - additional confidentiality protection. +: The packet number field is either 1, 2, or 4 bytes long. The packet number +has confidentiality protection separate from packet protection, as described in +Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is encoded +in the plaintext packet number. See {{packet-numbers}} for details. Protected Payload: @@ -466,13 +462,6 @@ The packet type in a short header currently determines only the size of the packet number field. Additional types can be used to signal the presence of other fields. -| Type | Packet Number Size | -|:-----|:-------------------| -| 0x0 | 1 octet | -| 0x1 | 2 octets | -| 0x2 | 4 octets | -{: #short-packet-types title="Short Header Packet Types"} - The header form and connection ID field of a short header packet are version-independent. The remaining fields are specific to the selected QUIC version. See {{QUIC-INVARIANTS}} for details on how packets from different @@ -786,15 +775,30 @@ reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; a server MAY send a Stateless Reset ({{stateless-reset}}) in response to further packets that it receives. -For the packet header, the number of bits required to represent the packet -number are reduced by including only the least significant bits of the packet -number. - -The encoded packet number is protected as described in {{QUIC-TLS}}. Protection -of the packet number is removed prior to recovering the full packet number. The -full packet number is reconstructed at the receiver based on the largest packet -number received on a successfully authenticated packet. Recovering the full -packet number is necessary to successfully remove packet protection. +In the QUIC long and short packet headers, the number of bits required to +represent the packet number are reduced by including only the least +significant bits of the packet number. + +In the long packet header, the least significant 32 bits are used. In the +short packet header, the number of significant bits are encoded in the most +significant two bits of the first octet of the encoded packet number: + +| First octet pattern | Encoded Length | Bits Present | +|:--------------------|:---------------|:-------------| +| 0b0xxxxxxx | 1 octet | 7 | +| 0b10xxxxxx | 2 | 14 | +| 0b11xxxxxx | 4 | 30 | + +Note that these encodings are similar to those in {{integer-encoding}}, but +use different values. + +The encoded packet number is protected as described in Section 5.6 {{QUIC-TLS}}. +Protection of the packet number is removed prior to recovering the full packet +number.The full packet number is reconstructed at the receiver based on the +value of the most significant two bits in the first octet (to determine the +number of least significant bits present), and the largest packet number +received on a successfully authenticated packet. Recovering the full packet +number is necessary to successfully remove packet protection. Once packet number protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet. From fae6da88e698925e5d19300f51e40167303c4497 Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Fri, 4 May 2018 21:20:59 +0200 Subject: [PATCH 2/9] tweaks, thanks Martin and Ian --- draft-ietf-quic-tls.md | 6 ++---- draft-ietf-quic-transport.md | 25 +++++++++++++++---------- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 7b53db015b..9a1680fbdd 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -962,10 +962,8 @@ expansion of the corresponding AEAD. Packet number protection is applied to the packet number encoded as described in Section 4.8 of {{QUIC-TRANSPORT}}. Since the length of the packet number is -stored in the encoded packet number, it is necessary to decrypt the maximum -length (4 octets) when removing packet number protection. The final 2 or 3 -octets of the plaintext packet number can then be discarded based on the -packet number length encoded in the first octet, as appropriate. +stored in the first octet of the encoded packet number, it may be necessary to +progressively decrypt the packet number. Before a TLS ciphersuite can be used with QUIC, a packet protection algorithm MUST be specifed for the AEAD used with that ciphersuite. This document defines diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3a62e290fe..bd4a2f7fb6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -779,26 +779,31 @@ In the QUIC long and short packet headers, the number of bits required to represent the packet number are reduced by including only the least significant bits of the packet number. -In the long packet header, the least significant 32 bits are used. In the -short packet header, the number of significant bits are encoded in the most -significant two bits of the first octet of the encoded packet number: +In the long packet header, the least significant 32 bits of the packet number +are encoded into the Packet Number field. + +In the short packet header, a variable number of significant bits are encoded. +One or two of the most significant bits of the first octet determine how many +bits of the packet number are provided, as shown in {{pn-encodings}}. | First octet pattern | Encoded Length | Bits Present | |:--------------------|:---------------|:-------------| | 0b0xxxxxxx | 1 octet | 7 | | 0b10xxxxxx | 2 | 14 | | 0b11xxxxxx | 4 | 30 | +{: #pn-encodings title="Short Header Packet Number Encodings"} + Note that these encodings are similar to those in {{integer-encoding}}, but use different values. -The encoded packet number is protected as described in Section 5.6 {{QUIC-TLS}}. -Protection of the packet number is removed prior to recovering the full packet -number.The full packet number is reconstructed at the receiver based on the -value of the most significant two bits in the first octet (to determine the -number of least significant bits present), and the largest packet number -received on a successfully authenticated packet. Recovering the full packet -number is necessary to successfully remove packet protection. +The encoded packet number is protected as described in Section 5.6 +{{QUIC-TLS}}. Protection of the packet number is removed prior to recovering +the full packet number. The full packet number is reconstructed at the +receiver based on the number of significant bits present, the content of those +bits, and the largest packet number received on a successfully authenticated +packet. Recovering the full packet number is necessary to successfully remove +packet protection. Once packet number protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet. From 50f05017ff449405fe14305a510e8b554a86668d Mon Sep 17 00:00:00 2001 From: Brian Trammell Date: Sat, 5 May 2018 21:26:03 +0200 Subject: [PATCH 3/9] long headers too --- draft-ietf-quic-transport.md | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bd4a2f7fb6..cfc7dc4387 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -282,7 +282,7 @@ keys are established. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Packet Number (32) | +| Packet Number (8/16/32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -344,11 +344,10 @@ Payload Length: Packet Number: -: The Packet Number is a 32-bit field that follows the two connection IDs. - Packet numbers are not encrypted as part of packet protection, but instead - have additional confidentiality protection. {{packet-numbers}} describes the - use of packet numbers. - +: The packet number field is 1, 2, or 4 octets long. The packet number has +confidentiality protection separate from packet protection, as described in +Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is encoded +in the plaintext packet number. See {{packet-numbers}} for details. Payload: @@ -449,8 +448,8 @@ Destination Connection ID: Packet Number: -: The packet number field is either 1, 2, or 4 bytes long. The packet number -has confidentiality protection separate from packet protection, as described in +: The packet number field is 1, 2, or 4 octets long. The packet number has +confidentiality protection separate from packet protection, as described in Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is encoded in the plaintext packet number. See {{packet-numbers}} for details. @@ -776,15 +775,10 @@ CONNECTION_CLOSE frame or any further packets; a server MAY send a Stateless Reset ({{stateless-reset}}) in response to further packets that it receives. In the QUIC long and short packet headers, the number of bits required to -represent the packet number are reduced by including only the least -significant bits of the packet number. - -In the long packet header, the least significant 32 bits of the packet number -are encoded into the Packet Number field. - -In the short packet header, a variable number of significant bits are encoded. -One or two of the most significant bits of the first octet determine how many -bits of the packet number are provided, as shown in {{pn-encodings}}. +represent the packet number are reduced by including only a variable number of +the least significant bits of the packet number. One or two of the most +significant bits of the first octet determine how many bits of the packet +number are provided, as shown in {{pn-encodings}}. | First octet pattern | Encoded Length | Bits Present | |:--------------------|:---------------|:-------------| @@ -793,7 +787,6 @@ bits of the packet number are provided, as shown in {{pn-encodings}}. | 0b11xxxxxx | 4 | 30 | {: #pn-encodings title="Short Header Packet Number Encodings"} - Note that these encodings are similar to those in {{integer-encoding}}, but use different values. From 4f8bb356a186f051ceefcd916a3a1570d7cf7d79 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 15:29:47 +1000 Subject: [PATCH 4/9] Both long and short have varint PN --- draft-ietf-quic-tls.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 9a1680fbdd..b61ed70ed8 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -941,14 +941,10 @@ Packet number protection is applied after packet protection is applied (see {{aead}}). The ciphertext of the packet is sampled and used as input to an encryption algorithm. -For packets with a long header, the ciphertext starting immediately after the -packet number is used. - -For packets with a short header, the packet number length is -assumed to be the smaller of the maximum possible packet -number encoding (4 octets), or the size of the protected packet minus the -minimum expansion for the AEAD. Thus, the sampled ciphertext for a short header -can be determined by: +In sampling the packet ciphertext, the packet number length is assumed to be the +smaller of the maximum possible packet number encoding (4 octets), or the size +of the protected packet minus the minimum expansion for the AEAD. For example, +the sampled ciphertext for a packet with a short header can be determined by: ``` sample_offset = min(1 + connection_id_length + 4, From 2320678b2058de2e0f37a581e7a88016dfecf582 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 15:30:37 +1000 Subject: [PATCH 5/9] TLS draft changes for protecting key phase with PN --- draft-ietf-quic-tls.md | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index b61ed70ed8..906d4b37be 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -829,13 +829,12 @@ N_MIN set to 12). The size of the packet protection key is determined by the packet protection algorithm, see {{pn-encrypt}}. -For any secret S, the AEAD key uses a label of "key", the IV uses a label of -"iv", packet number encryption uses a label of "pn": +For any secret S, the AEAD key uses a label of "key", and the IV uses a label of +"iv": ~~~ key = QHKDF-Expand(S, "key", key_length) iv = QHKDF-Expand(S, "iv", iv_length) -pn_key = QHKDF-Expand(S, "pn", pn_key_length) ~~~ Separate keys are derived for packet protection by clients and servers. Each @@ -847,7 +846,6 @@ derived from 1-RTT secrets as follows: ~~~ client_pp_key = QHKDF-Expand(client_pp_secret, "key", 16) client_pp_iv = QHKDF-Expand(client_pp_secret, "iv", 12) -client_pp_pn = QHKDF-Expand(client_pp_secret, "pn", 12) ~~~ The QUIC packet protection initially starts with keying material derived from @@ -933,9 +931,25 @@ to QUIC. ## Packet Number Protection {#pn-encrypt} QUIC packets are protected using a key that is derived from the current set of -secrets. The key derived using the "pn" label is used to protect the packet -number from casual observation. The packet number protection algorithm depends -on the negotiated AEAD. +secrets. A packet protection key is used to protect the packet number from +casual observation. The packet number protection key is derived from the first +packet protection secret using the label "pn". This key is produced using the +same process as the AEAD key and IV, but the value is not updated with each key +update ({{key-update}}). + +~~~ +pn_key = QHKDF-Expand(pp_secret<0>, "pn", pn_key_length) +~~~ + +That is, for the algorithms defined in this document, the packet protection key +is determined to be: + +~~~ +client_pn_key = QHKDF-Expand(client_pp_secret<0>, "pn", 16) +server_pn_key = QHKDF-Expand(server_pp_secret<0>, "pn", 16) +~~~ + +The packet number protection algorithm depends on the negotiated AEAD. Packet number protection is applied after packet protection is applied (see {{aead}}). The ciphertext of the packet is sampled and used as input to an @@ -952,9 +966,9 @@ sample_offset = min(1 + connection_id_length + 4, sample = packet[sample_offset..sample_offset+sample_length] ``` -To ensure that this process does not sample the packet number, packet number -protection algorithms MUST NOT sample more ciphertext than the minimum -expansion of the corresponding AEAD. +To ensure that this process does not sample the packet number and key phase, +packet number protection algorithms MUST NOT sample more ciphertext than the +minimum expansion of the corresponding AEAD. Packet number protection is applied to the packet number encoded as described in Section 4.8 of {{QUIC-TRANSPORT}}. Since the length of the packet number is From d20076693596b91d3baadfdd92d54a438caaad02 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 15:51:45 +1000 Subject: [PATCH 6/9] Move the KEY_PHASE into the short header packet number encoding --- draft-ietf-quic-transport.md | 73 +++++++++++++++++++++++------------- 1 file changed, 46 insertions(+), 27 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cfc7dc4387..547748d5d2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -385,11 +385,11 @@ See {{packet-coalesce}} for more details. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ -|0|K|1|1|0|R R R| +|0|0|1|1|0|R R R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Connection ID (0..144) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Packet Number (8/16/32) ... +|K| Packet Number (7/15/31) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -403,11 +403,10 @@ Header Form: : The most significant bit (0x80) of octet 0 is set to 0 for the short header. -Key Phase Bit: +Second Bit: -: The second bit (0x40) of octet 0 indicates the key phase, which allows a - recipient of a packet to identify the packet protection keys that are used to - protect the packet. See {{QUIC-TLS}} for details. +: The second bit (0x40) is reserved. Endpoints MUST set this value to zero and + ignore any non-zero value unless a use for this bit has been negotiated. \[\[Editor's Note: this section should be removed and the bit definitions changed before this draft goes to the IESG.]] @@ -446,12 +445,19 @@ Destination Connection ID: : The Destination Connection ID is a connection ID that is chosen by the intended recipient of the packet. See {{connection-id}} for more details. +Key Phase Bit (K): + +: The most significant octet of the packet number includes the key phase, which + allows a recipient of a packet to identify the packet protection keys that are + used to protect the packet. See {{QUIC-TLS}} for details. + Packet Number: -: The packet number field is 1, 2, or 4 octets long. The packet number has -confidentiality protection separate from packet protection, as described in -Section 5.6 of {{QUIC-TLS}}. The length of the packet number field is encoded -in the plaintext packet number. See {{packet-numbers}} for details. +: The packet number field is the remainder of a 1, 2, or 4 octet field. The + packet number has confidentiality protection separate from packet protection, + as described in Section 5.6 of {{QUIC-TLS}}. The length of the packet number + field is encoded in the plaintext packet number. See {{packet-numbers}} for + details. Protected Payload: @@ -776,27 +782,40 @@ Reset ({{stateless-reset}}) in response to further packets that it receives. In the QUIC long and short packet headers, the number of bits required to represent the packet number are reduced by including only a variable number of -the least significant bits of the packet number. One or two of the most -significant bits of the first octet determine how many bits of the packet -number are provided, as shown in {{pn-encodings}}. - -| First octet pattern | Encoded Length | Bits Present | -|:--------------------|:---------------|:-------------| -| 0b0xxxxxxx | 1 octet | 7 | -| 0b10xxxxxx | 2 | 14 | -| 0b11xxxxxx | 4 | 30 | -{: #pn-encodings title="Short Header Packet Number Encodings"} +the least significant bits of the packet number. In the long header format, one +or two of the most significant bits of the first octet determine how many bits +of the packet number are provided, as shown in {{long-pn-encodings}}. + +| First Octet Pattern | Encoded Length | Bits For PN | +|:--------------------|:---------------|:------------| +| 0xxxxxxx | 8 bits | 7 | +| 10xxxxxx | 16 bits | 14 | +| 11xxxxxx | 32 bits | 30 | +{: #long-pn-encodings title="Long Header Packet Number Encodings"} + +The short header format, the first bit of the encoding is reserved for the +KEY_PHASE bit (see Section 6 of {{QUIC-TLS}}). The remainder of that octet uses +the same prefix as that used for the long header packet number encoding. The +result is that one fewer bit from the packet number can be included, as shown in +{{short-pn-encodings}}. + +| First Octet Pattern | Encoded Length | Bits For PN | +|:--------------------|:---------------|:------------| +| K0xxxxxx | 8 bits | 6 | +| K10xxxxx | 16 bits | 13 | +| K11xxxxx | 32 bits | 29 | +{: #short-pn-encodings title="Short Header Packet Number Encodings"} Note that these encodings are similar to those in {{integer-encoding}}, but use different values. -The encoded packet number is protected as described in Section 5.6 -{{QUIC-TLS}}. Protection of the packet number is removed prior to recovering -the full packet number. The full packet number is reconstructed at the -receiver based on the number of significant bits present, the content of those -bits, and the largest packet number received on a successfully authenticated -packet. Recovering the full packet number is necessary to successfully remove -packet protection. +The encoded packet number and KEY_PHASE (if present) is protected as described +in Section 5.6 {{QUIC-TLS}}. Protection of the packet number is removed prior to +recovering the full packet number. The full packet number is reconstructed at +the receiver based on the number of significant bits present, the content of +those bits, and the largest packet number received on a successfully +authenticated packet. Recovering the full packet number is necessary to +successfully remove packet protection. Once packet number protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet. From 3335dd5cb78cc2c150f822153221d938d03a3980 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 16:08:47 +1000 Subject: [PATCH 7/9] Update examples for shorter encodings --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cfc7dc4387..219655fd6c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -802,7 +802,7 @@ Once packet number protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet. The next expected packet is the highest received packet number plus one. For example, if the highest successfully authenticated packet had a packet number of -0xaa82f30e, then a packet containing a 16-bit value of 0x1f94 will be decoded as +0xaa82f30e, then a packet containing a 14-bit value of 0x1f94 will be decoded as 0xaa831f94. The sender MUST use a packet number size able to represent more than twice as @@ -818,9 +818,9 @@ the base 2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. For example, if an endpoint has received an acknowledgment for packet 0x6afa2f, -sending a packet with a number of 0x6b4264 requires a 16-bit or larger packet -number encoding; whereas a 32-bit packet number is needed to send a packet with -a number of 0x6bc107. +sending a packet with a number of 0x6b2d79 requires a packet number encoding +with 14 bits or more; whereas the 30-bit packet number encoding is needed to +send a packet with a number of 0x6bc107. A Version Negotiation packet ({{packet-version}}) does not include a packet number. The Retry packet ({{packet-retry}}) has special rules for populating From 38afa0121ee51cf9499e8e14675ee8094ba34317 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 16:35:43 +1000 Subject: [PATCH 8/9] Superficial only --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 547748d5d2..50cf470f04 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -806,8 +806,8 @@ result is that one fewer bit from the packet number can be included, as shown in | K11xxxxx | 32 bits | 29 | {: #short-pn-encodings title="Short Header Packet Number Encodings"} -Note that these encodings are similar to those in {{integer-encoding}}, but -use different values. +Note that these encodings are superficially similar to those in +{{integer-encoding}}, but use different prefixes. The encoded packet number and KEY_PHASE (if present) is protected as described in Section 5.6 {{QUIC-TLS}}. Protection of the packet number is removed prior to From 129d1201a5fdf4f38f3378c675a7b695a588c607 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 May 2018 16:38:03 +1000 Subject: [PATCH 9/9] Update examples for varying sizes --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d61d9c7d13..b2f54c6a56 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -822,7 +822,7 @@ finding the packet number value that is closest to the next expected packet. The next expected packet is the highest received packet number plus one. For example, if the highest successfully authenticated packet had a packet number of 0xaa82f30e, then a packet containing a 14-bit value of 0x1f94 will be decoded as -0xaa831f94. +0xaa831f94; the same value encoded on 13 bits will be decoded as 0xaa82ff94. The sender MUST use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and @@ -838,8 +838,8 @@ including the new packet. For example, if an endpoint has received an acknowledgment for packet 0x6afa2f, sending a packet with a number of 0x6b2d79 requires a packet number encoding -with 14 bits or more; whereas the 30-bit packet number encoding is needed to -send a packet with a number of 0x6bc107. +with 13 bits or more; whereas the 29- or 30-bit packet number encoding is needed +to send a packet with a number of 0x6bc107. A Version Negotiation packet ({{packet-version}}) does not include a packet number. The Retry packet ({{packet-retry}}) has special rules for populating