Re: [quicwg/base-drafts] First pass at 7, 14, and 30-bit varint packet numbers (#1334)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Thanks for writing this up Brian.  90% of the way there already.

> @@ -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

It isn't *strictly* necessary to decrypt 4 octets: you can decrypt one octet at a time.

One thing that concerns me here is that you are recommending a strategy that includes decrypting the IV; I don't know how to exploit that and it seems entirely possible that it can't be, but I would avoid recommending this implementation strategy (even if I have in the past; I'm not sure that I want that in an RFC).

Instead, I would observe that the packet number might need to progressively decrypted.

> @@ -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.

I think that this is a fine thing.  Removing type is good; reserving is good.

I would more simply state this as "these bits are reserved".  We might ultimately decide that the spin bit experiment is an experiment no longer.  At that point we might assign them to the spin bit(s) or find an entirely different use for those bits.

> @@ -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

"In the long packet header, the least significant 32 bits of the packet are encoded into the Packet Number field."

> -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:

`<p>`
"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}}."

> -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           |
+

{: #pn-encodings title="Short Header Packet Number Encodings"}

> +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

I like Ian's suggestion too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1334#pullrequestreview-117479433