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

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



>  
-For example, the sampled ciphertext for a packet with a short header can be
-determined by:
+
+### Header Protection Application
+
+Header 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.  The algorithm used depends on the negotiated AEAD.
+
+The output of this algorithm is 5 bytes of mask which are applied to the
+protected using exclusive OR.  The least significant bits of the first byte of

```suggestion
protected header fields using exclusive OR.  The least significant bits of the first byte of
```

>  
-For example, the sampled ciphertext for a packet with a short header can be
-determined by:
+
+### Header Protection Application
+
+Header 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.  The algorithm used depends on the negotiated AEAD.
+
+The output of this algorithm is 5 bytes of mask which are applied to the

```suggestion
The output of this algorithm is a 5 byte mask which is applied to the
```

> -For example, the sampled ciphertext for a packet with a short header can be
-determined by:
+
+### Header Protection Application
+
+Header 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.  The algorithm used depends on the negotiated AEAD.
+
+The output of this algorithm is 5 bytes of mask which are applied to the
+protected using exclusive OR.  The least significant bits of the first byte of
+the packet are masked by the first mask byte, and the packet number is masked
+with the remaining bytes.
+
+{{pseudo-hp}} shows a sample algorithm for applying header protection. Removing
+protection only differs in the order in which the packet number length

```suggestion
header protection only differs in the order in which the packet number length
```

> +The output of this algorithm is 5 bytes of mask which are applied to the
+protected using exclusive OR.  The least significant bits of the first byte of
+the packet are masked by the first mask byte, and the packet number is masked
+with the remaining bytes.
+
+{{pseudo-hp}} shows a sample algorithm for applying header protection. Removing
+protection only differs in the order in which the packet number length
+(pn_length) is determined.
+
+~~~
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] & 0x03) + 1
+if packet[0] & 0x80 == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] & 0x0f

```suggestion
   packet[0] ^= (mask[0] & 0x0f)
```

> +with the remaining bytes.
+
+{{pseudo-hp}} shows a sample algorithm for applying header protection. Removing
+protection only differs in the order in which the packet number length
+(pn_length) is determined.
+
+~~~
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] & 0x03) + 1
+if packet[0] & 0x80 == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] & 0x0f
+else:
+   # Short header: 5 bits masked
+   packet[0] ^= mask[0] & 0x1f

```suggestion
   packet[0] ^= (mask[0] & 0x1f)
```

(in line with other places where extra parentheses are added to remove all ambiguity)

> +with the remaining bytes.
+
+{{pseudo-hp}} shows a sample algorithm for applying header protection. Removing
+protection only differs in the order in which the packet number length
+(pn_length) is determined.
+
+~~~
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] & 0x03) + 1
+if packet[0] & 0x80 == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] & 0x0f
+else:
+   # Short header: 5 bits masked
+   packet[0] ^= mask[0] & 0x1f

```suggestion
   packet[0] ^= (mask[0] & 0x1f)
```

> +protection only differs in the order in which the packet number length
+(pn_length) is determined.
+
+~~~
+mask = header_protection(hp_key, sample)
+
+pn_length = (packet[0] & 0x03) + 1
+if packet[0] & 0x80 == 0x80:
+   # Long header: 4 bits masked
+   packet[0] ^= mask[0] & 0x0f
+else:
+   # Short header: 5 bits masked
+   packet[0] ^= mask[0] & 0x1f
+
+# pn_offset is the start of the Packet Number field.
+packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]

```suggestion
packet[pn_offset:pn_offset+pn_length] ^= (mask[1:1+pn_length])
```
I'm not sure the range notation is clearly understood - some consider the end inclusive, others exclusive. 0-based is also not clear, but at least that is clear from context in this case.

> +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
+there is insufficient space in the packet for a complete sample.  The starting
+offset for the sample is set to 4 bytes after the start of the Packet Number
+field, then is reduced until there are enough bytes to sample.

It's not clear if "enough to sample" means there should always be 5 bytes - since earlier text says this - or just enough to cover the obviously shorter packer number thereby reducing the mask length.

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   [Protected Payload (8/16/24)]             ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|             Sampled part of Protected Payload (128)         ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                 Protected Payload Remainder (*)             ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #fig-sample title="Header Protection and Ciphertext Sample"}
+
+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}}.
+

Perhaps clarify where the algorithm is chosen - it is fixed AEAD_AES_128_GCM in initial packets and TLS selected later on.

> -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 17.1 of {{QUIC-TRANSPORT}}. Since the length of the packet number is
-stored in the first byte 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
-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}}).
+To ensure that this process does not sample the packet number, header protection
+algorithms MUST NOT require sample that is longer than the minimum expansion of
+the corresponding AEAD.
 

Again, it was earlier statet that the mask has length 5, but here is seems to depend on PN 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.
-
-Packet number protection is applied to the packet number encoded as described in
-Section 17.1 of {{QUIC-TRANSPORT}}. Since the length of the packet number is
-stored in the first byte 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
-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}}).
+To ensure that this process does not sample the packet number, header protection
+algorithms MUST NOT require sample that is longer than the minimum expansion of

```suggestion
algorithms MUST NOT require a sample that is longer than the minimum expansion of
```

>  ~~~
 
 This construction is secure against chosen plaintext attacks (IND-CPA) {{IMC}}.
 
 Use of the same key and ciphertext sample more than once risks compromising
-packet number protection. Protecting two different packet numbers with the same
-key and ciphertext sample reveals the exclusive OR of those packet numbers.
-Assuming that the AEAD acts as a PRF, if L bits are sampled, the odds of two
-ciphertext samples being identical approach 2^(-L/2), that is, the birthday
-bound. For the algorithms described in this document, that probability is one in
-2^64.
+header protection. Protecting two different headers with the same key and
+ciphertext sample reveals the exclusive OR of the protected fields.  Assuming
+that the AEAD acts as a PRF, if L bits are sampled, the odds of two ciphertext
+samples being identical approach 2^(-L/2), that is, the birthday bound. For the
+algorithms described in this document, that probability is one in 2^64.
 

Is this probality still true for PN's shorter than 4 bytes? Or even at all given that the mask is at most only 36  or 37 bits effectively?

> @@ -3271,15 +3257,35 @@ Header Form:
 : The most significant bit (0x80) of byte 0 (the first byte) is set to 1 for
   long headers.
 
-Long Packet Type:
+Fixed Bit:
+
+: The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value
+  for this bit are not valid packets in this version.

@marten-seemann I believe there a general section on dropping invalid handshake packets. But the following paragraphs says to raise a protocol violation - which only makes sense if the packet is authenticated. Either way, I think this paragraph needs to be consistent with the other fields.

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

@marten-seemann You mean decrypted/authenticated?

-- 
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#pullrequestreview-175287095