Re: [quicwg/base-drafts] First byte changes (#2006)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.



> @@ -771,10 +771,9 @@ 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.
 
-QUIC packets are protected prior to applying packet number protection
-({{pn-encrypt}}).  The unprotected packet number is part of the associated data
-(A).  When removing packet protection, an endpoint first removes the protection
-from the packet number.
+Packets are protected prior to applying header protection ({{header-protect}}).

Sigh. Naming. So how about two nouns: "packet protection" and "header protection". They're both imperfect, but at least accurate. I would then eschew usages like "Packets are protected" in favor of "Packet protection is applied".

> +Before a TLS ciphersuite can be used with QUIC, a header protection algorithm
+MUST be specified for the AEAD used with that ciphersuite.  This document
+defines algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM,
+AEAD_AES_256_CCM (all AES AEADs are defined in {{!AEAD=RFC5116}}), and
+AEAD_CHACHA20_POLY1305 {{!CHACHA=RFC8439}}.
+
+
+### Header Protection Sample {#hp-sample}
+
+The header protection algorithm uses both the header protection key and a sample
+of the ciphertext from the packet Payload field.
+
+The same number of bytes are always sampled, but an allowance needs to be made
+for the endpoint removing protection, which will not know the length of the
+Packet Number field.  In sampling the packet ciphertext, the Packet Number field
+is assumed to be 4 bytes long (its maximum possible encoded length), unless

This discussion belongs on #1575, and at any rate, I would not make this a reason for blocking this PR. I would argue that we get in what we've agreed on (which is this PR), and then continue discussion on simplification on #1575.

>  
-: The fourth bit (0x10) of byte 0 is set to 1.
+: The next two bits (those with a mask of 0x18) of byte 0 are reserved.  These
+  bits are protected using header protection (see Section 5.4 of
+  {{QUIC-TLS}}).  The value included prior to protection MUST be set to 0.  An

This conversation is getting carried away. @igorlord: If the bits can be anything, and if middleboxes start using those bits as scratch space, they're effectively ossified. Endpoints can't use them anymore, since middleboxes might stomp on them in the network. How do we counter that?

>  
-: The fourth bit (0x10) of byte 0 is set to 1.
+: The next two bits (those with a mask of 0x18) of byte 0 are reserved.  These
+  bits are protected using header protection (see Section 5.4 of
+  {{QUIC-TLS}}).  The value included prior to protection MUST be set to 0.  An
+  endpoint MUST treat receipt of a packet that has a non-zero value for these
+  bits after removing protection as a connection error of type
+  PROTOCOL_VIOLATION.

Ah, right. @martinthomson it might be worth clarifying that this is "packet protection" (see nomenclature note above)

>    confidentiality protection separate from packet protection, as described in
-  Section 5.3 of {{QUIC-TLS}}. The length of the packet number field is encoded
+  Section 5.4 of {{QUIC-TLS}}. The length of the packet number field is encoded
   in the plaintext packet number. See {{packet-encoding}} for details.
 

@huitema The Packet Number Length field is the last two bits of the first byte (see 2 paragraphs above).

-- 
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/2006#discussion_r234842343