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

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Nov 2018 20:11:59 -0800

This is a first draft of the changes that we discussed, first in NYC, then confirmed in Bangkok.

I had to recast "packet number protection" as header protection, but I took the opportunity to expand the text and organize it some more.  I'm not especially happy with the picture, and could probably drop that, but I think that the changes clarify the process more.

The changes are all exactly as discussed, except that I ended up moving the ODCIL field from the Retry packet, which conveniently fit into four bits that I was struggling to describe what to do with.  The low four bits in Retry can't be protected because Retry packets aren't protected.  This seemed like a neat way of handling that.

I'm not certain that these are the only changes needed, but I think that this is essentially complete.  It's good to get everything nailed down finally.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2006

-- Commit Summary --

  * Rough in first octet changes
  * Add the TLS bits, refine some of the transport bits
  * Reword

-- File Changes --

    M draft-ietf-quic-tls.md (212)
    M draft-ietf-quic-transport.md (209)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2006.patch
https://github.com/quicwg/base-drafts/pull/2006.diff

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 14 Nov 2018 20:52:32 -0800

marten-seemann commented on this pull request.

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

Should we say that those packets are supposed to be dropped?

> @@ -3353,8 +3354,8 @@ following sections.
 The end of the packet is determined by the Length field.  The Length field
 covers both the Packet Number and Payload fields, both of which are
 confidentiality protected and initially of unknown length.  The size of the
-Payload field is learned once the packet number protection is removed.  The
-Length field enables packet coalescing ({{packet-coalesce}}).
+Payload field is learned once the header protection is removed.  The Length

Why is that? The Payload Length is not encrypted, is it?

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

Same here.

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

This doesn't say anything about peers that are not spinning, in which case it should be 6 bits.

-\[\[Editor's Note: this section should be removed and the bit definitions
-changed before this draft goes to the IESG.]]
+: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
+  {{!SPIN=I-D.ietf-quic-spin-exp}}.

Do we need to say something about peers that are not spinning?

> @@ -3677,7 +3666,7 @@ wishes to perform a stateless retry (see {{validate-handshake}}).
  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
 +-+-+-+-+-+-+-+-+
-|1|    0x7e     |
+|1|1| 3 |ODCIL(4|

It's kind of weird to have the ODCIL length field so far before the ODCIL. On the other hand, it saves a byte, and fills unused bits.

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

This only applies to packets that are successfully encrypted. Should we mention that?

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 14 Nov 2018 21:02:26 -0800

IIUC, this PR breaks key updates, doesn't it? Since the Key Phase bit is encrypted, an endpoint won't be able to notice that a key update happened, and try the wrong key for unprotecting the header.

-- 
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#issuecomment-438918469

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 14 Nov 2018 21:54:17 -0800

kazuho commented on this pull request.

What is not encrypted is the "Length" field that represents the sum of the packet number size and payload size.

The length of the payload is revealed by obtaining the size of the packet number field by removing the header protection.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 14 Nov 2018 21:58:08 -0800

@marten-seemann 
> IIUC, this PR breaks key updates, doesn't it? Since the Key Phase bit is encrypted, an endpoint won't be able to notice that a key update happened, and try the wrong key for unprotecting the header.

I am not sure if that is true, because header protection key remains consistent between Key Updates.

-- 
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#issuecomment-438927219

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 14 Nov 2018 22:04:35 -0800

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

I think that you might want to call the AEAD process "payload protection", rather than referring to it like "packets are protected". IMO doing so would better clarify that we have two encryption: one that encrypts the payload and one that encrypts the header.

I understand that such change puts burden on the editors, so just saying.

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 14 Nov 2018 23:34:46 -0800

Thanks for the explanation. Apparently I completely misunderstand this sentence, and the source of the confusion is that the payload is call "Payload field".

Suggested change:
"The length of the payload is learned once the header protection is removed."

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 00:40:51 -0800

+

My understanding is that we cannot change which bits are protected based on the use (or non-use) is spin bits, because the use is not negotiated.

Having the bit always outside the header protection also gives the non-participating endpoints greater freedom to play with the bits (e.g. always set to zero).

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 00:44:27 -0800

I share the view that the design is consistent with what we have discussed in New York. Thank you Martin for making this happen.

-- 
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#issuecomment-438962123

---

From: janaiyengar <[email-masked]>
Date: Thu, 15 Nov 2018 03:35:20 -0800

janaiyengar commented on this pull request.

+1. I think this clarity will help.

> -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 size larger than the minimum expansion of
```

> @@ -3050,6 +3050,7 @@ IP addresses has fallen below 1280 bytes, it MUST immediately cease sending QUIC
 packets on the affected path.  This could result in termination of the
 connection if an alternative path cannot be found.
 
+

```suggestion
```

> -number of bits required to represent the packet number is first 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 byte are then used
-to represent how many bits of the packet number are provided, as shown in
-{{pn-encodings}}.
-
-| First byte pattern | Encoded Length | Bits Present |
-|:-------------------|:---------------|:-------------|
-| 0b0xxxxxxx         | 1 byte         | 7            |
-| 0b10xxxxxx         | 2              | 14           |
-| 0b11xxxxxx         | 4              | 30           |
-{: #pn-encodings title="Packet Number Encodings for Packet Headers"}
-
-Note that these encodings are similar to those in {{integer-encoding}}, but
-use different values.
+Packet numbers in long and short packet headers are encoded on 1 to 4 octets.

```suggestion
Packet numbers in long and short packet headers are encoded in 1 to 4 octets.
```

> -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 byte are then used
-to represent how many bits of the packet number are provided, as shown in
-{{pn-encodings}}.
-
-| First byte pattern | Encoded Length | Bits Present |
-|:-------------------|:---------------|:-------------|
-| 0b0xxxxxxx         | 1 byte         | 7            |
-| 0b10xxxxxx         | 2              | 14           |
-| 0b11xxxxxx         | 4              | 30           |
-{: #pn-encodings title="Packet Number Encodings for Packet Headers"}
-
-Note that these encodings are similar to those in {{integer-encoding}}, but
-use different values.
+Packet numbers in long and short packet headers are encoded on 1 to 4 octets.
+The number of bits required to represent the packet number reduced by including

```suggestion
The number of bits required to represent the packet number is reduced by including
```

> @@ -3210,27 +3196,27 @@ arrives after many higher-numbered packets have been received.  An endpoint
 SHOULD use a large enough packet number encoding to allow the packet number to
 be recovered even if the packet arrives after packets that are sent afterwards.
 
-As a result, the size of the packet number encoding is at least one more than
-the base 2 logarithm of the number of contiguous unacknowledged packet numbers,
-including the new packet.
+As a result, the size of the packet number encoding is at least one bit more
+than the base 2 logarithm of the number of contiguous unacknowledged packet

```suggestion
than the base-2 logarithm of the number of contiguous unacknowledged packet
```

-Long Packet Type:
+Fixed Bit:
+

For consistency, I would say that receipt of zero here should be treated  as a connection error of type PROTOCOL_VIOLATION.

-Third Bit:

... same error here.

I think we should leave that to the other doc.

@marten-seemann : did you mean "after successfully removing header protection"? I don't think you need to wait to remove packet / payload protection before doing this. 

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 03:36:41 -0800

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

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

+

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

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

+

```suggestion
   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.

+the corresponding AEAD.

Again, it was earlier statet that the mask has length 5, but here is seems to depend on PN length.

```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?

-Long Packet Type:
+Fixed Bit:
+

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

@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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Nov 2018 11:39:08 +0000 (UTC)

-Long Packet Type:
+Fixed Bit:
+

@janaiyengar: I was thinking of a fast-path processing here: I can check this bit without decrypting the packet, so if I receive a packet with 0x40 == 0, I know it's some UDP garbage, and I can drop it on the floor immediately.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Nov 2018 03:41:01 -0800

+

Why can't we? If I decide to not spin (in general, or just for this connection / CID), I can apply header protection to that bit as well. This would provide optimal greasing.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 03:41:30 -0800

There is some overlap between Jana's and my comments as they were submitted at the same time.

-- 
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#issuecomment-439012190

---

From: Marten Seemann <[email-masked]>
Date: Thu, 15 Nov 2018 03:43:30 -0800

Sorry for the confusion. I meant "removing packet protection" (not header protection). The reason is that header protection is not authenticated, so an attacker can send a packet, and we'll happily remove header protection (and receive some garbage values). Only when we try to remove packet protection will we discover that this packet was not sent by the peer.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 03:47:58 -0800

I forget that the sample is a block size input to a encryption step.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 03:48:41 -0800

I think I'm mixing up the block size input to the encryption with the extracted mask output. The input is always fixed size but depends on AEAD.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 05:58:16 -0800

-Long Packet Type:
+Fixed Bit:
+

Yeah we have two choices:
* drop the apparently broken packet without even decrypting it
* decrypt and verify the AEAD tag of the apparently broken packet, then close the connection with PROTOCOL_VIOLATION

I tend to agree what @marten-seemann that we do not need to decrypt in this case. Let's handle it the same way as handling a packet with a broken AEAD tag.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 06:00:01 -0800

+

To reconstruct the AAD that was used, the receiver needs to know if you have applied header protection to the spin bit. However, if you are using spin bit is never signaled to the peer.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 06:03:08 -0800

+

Unused spins are currently required to be a constant value randomly chosen to be 0 or 1. Not sure why, but encrypting it would violate that.

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

---

From: ianswett <[email-masked]>
Date: Thu, 15 Nov 2018 09:49:55 -0800

ianswett commented on this pull request.

+

One reason to choose a fixed value per connection is it makes it easier to detect which connections are not spinning.  Another reason is it's easy to leak information in that bit, so it's safer to just set a fixed value.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 13:23:23 -0800

> @@ -850,55 +939,45 @@ if packet_type == Initial:
                      len(token)
 ~~~

Benjamin Saunders pointed out on Slack that the long header pseudo code does not check for out of bounds condition when the packet is small.

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:16:21 -0800

DavidSchinazi commented on this pull request.

+

```suggestion
if (packet[0] & 0x80) == 0x80:
```

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:18:53 -0800

+

@marten-seemann you can grease this bit without encrypting it - just send a different random value with every packet. I would prefer to keep the spec simpler by never encrypting this bit.

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

---

From: erickinnear <[email-masked]>
Date: Thu, 15 Nov 2018 14:21:05 -0800

erickinnear commented on this pull request.

+

@ianswett I think you can still tell which connections aren't spinning even if set to a random value. But I agree about leaking information unintentionally. 

I'd also like to make sure we grease this bit, but I would be fine with doing that in a way that doesn't involve encrypting it with the rest of the packet. 

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 22:22:14 +0000 (UTC)

+

@DavidSchinazi The simplest way to randomize it is to encrypt it, but as Ian says, there are reasons not to do this.

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:23:51 -0800

Shouldn't this pseudo-code define how `sample` is computed first? The spec only defines it further down (in `#hp-sample`) so we may want to reorder the pseudo-code to somewhere after that

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:33:22 -0800

Now that we have this PR, I'd like to reopen [the discussion of PNE simplification I proposed a while back](https://github.com/quicwg/base-drafts/issues/1575#issuecomment-425662595). Given the text in this PR, my proposal would be to require that QUIC packets MUST verify `length(packet number) + length(payload) >= 4`. Then you can remove this "unless" clause which simplifies both encryption and decryption. (Unlike my previous proposal, we would now only encrypt the packet number (not the start of the payload) since we get the packet number length from the first byte.

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:41:28 -0800

>  pseudocode:
 
 ~~~
 counter = DecodeLE(sample[0..3])
 nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15])
-encrypted_pn = ChaCha20(pn_key, counter, nonce, packet_number)
+mask = ChaCha20(pn_key, counter, nonce, 0)

```suggestion
mask = ChaCha20(pn_key, counter, nonce, {0,0,0,0,0})
```

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:53:09 -0800

I'm confused by this sentence. Did you mean "The number of bits required to represent the packet number is deduced by observing the two least significant bits of the first byte." or something completely different?

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Nov 2018 14:55:22 -0800

The current proposal does not encrypt any payload - I think an earlier iteration did.

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 14:58:20 -0800

Reading further down I'm actually understanding the meaning now - perhaps we could rephrase to something like: "Since we have information about which previous packet numbers have been acknowledged, it is possible to only send some of the least significant bits of the packet number when they are sufficient to reconstruct the full packet number unambiguously."

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 17:58:46 -0800

-Third Bit:

Just wanted to note that forcing bit 0x40 to 1 is critical to Google's demultiplexing. We were using 0x08 (the "Google QUIC Demultiplexing Bit") but since 0x08 is now encrypted we'll be using this one. So please keep this at 1, at least for short headers. Thanks!

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 18:18:10 -0800

@martinthomson 
> I'm not certain that these are the only changes needed, but I think that this is essentially complete.

I think you also need to update the diagram of the Stateless Reset packet.

-- 
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#issuecomment-439259022

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 15 Nov 2018 20:12:42 -0800

dtikhonov commented on this pull request.

-Third Bit:

Agreed: keeping 0x40 will mean that servers will be able to support pre-Q044 clients as well.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 15 Nov 2018 22:55:16 -0800

As pointed out by @huitema elsewhere, we might start seeing cipher-suites that use smaller-sized tags.

For example, the TLS_AES_128_CCM_8_SHA256 cipher-suite defined in [TLS 1.3](https://tools.ietf.org/html/rfc8446) uses a 64-bit tag, meaning that the shortest possible IV passed to the header protection would be just 72-bits.

Considering that, I think it might be safer to require senders to pad the payload so that there would be at least 128 bits of IV.

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Nov 2018 23:18:35 -0800

I would be inclined to disallow TLS_AES_128_CCM_8_SHA256 in QUIC but either way padding the payload is a viable solution

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 15 Nov 2018 23:33:22 -0800

huitema commented on this pull request.

I think this sentence really means, "compared to the previous draft, the number of bits required to encode the PN is reduced, because we steal 2 bits from the first octet." Which makes sense now as we are arguing about details, but really does not belong in the final spec. In the final spec, the encoding is what it is, and that's it.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Nov 2018 01:47:01 -0800

martinthomson commented on this pull request.

+

No, that doesn't work, because the value of the spin bit is covered by the AAD, and we have to have peers agree on what the value is.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 16 Nov 2018 10:40:33 +0000 (UTC)

I don't think the privacy implications of the header encryption are significant enough to require an IV longer than the AEAD tag, and if they are, choose an algorithm that works. Some applications outside of UDP might want really small fast packets for signalling, like ABS brakes or something.

BTW: I thought all tags were currently 16 bytes?

https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#aead

> All ciphersuites currently defined for TLS 1.3 - and therefore QUIC - have a 16-byte authentication tag and produce an output 16 bytes larger than their input.

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

---

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 16 Nov 2018 12:08:08 -0800

djc commented on this pull request.

                      len(token)
 ~~~

Yes; as an implementer (and the reason Benjamin asked about this) I looked at the example code more than the surrounding prose, and incorrectly assumed the offset adjustment only applies for short header packets. It would be nice to clarify this somehow, either by duplicating that bit of code for the long header example code, or by separating it more from the short header example code to clarify that it applies to both.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Nov 2018 15:07:45 -0800

@martinthomson pushed 1 commit.

b40e506  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/0e361883372606c2d4476c6ed8f21f95958cf1db..b40e506d9c905f6a8073849d10cc43fd3248f8dd

---

From: Marten Seemann <[email-masked]>
Date: Fri, 16 Nov 2018 17:46:38 -0800

What's the worst case scenario here? According to my understanding, if I reuse the IV in AES-CTR, an observer will be able to obtain the XOR of the plain texts. But that's all, I'm not compromising the header encryption keys.
Is that correct?

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

---

From: Marten Seemann <[email-masked]>
Date: Fri, 16 Nov 2018 17:51:11 -0800

Editorial: Didn't we agree on "byte" instead of "octet"?

-- 
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#issuecomment-439577820

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 16 Nov 2018 19:25:13 -0800

@mikkelfj I tend to agree that 128 bits will be enough (because PN space is 62 bits and IV needs to be indistinguishable from random), but I think we might want to define the number for each cipher-suite.

@marten-seemann The reason we introduced PNE was to prevent packet numbers sent in clear as a tracking vector among multiple CIDs of a connection (that possibly roams). As you state, IV collision leaks the XOR between two packet numbers. The risk of that being used as a tracking vector will become higher as the chance of collision arises.

Anyways, I think that requiring `length(packet number) + length(payload) >= 4 + length(iv) - length(aead tag)` would be a good idea, because it is a simplification at the same time giving us agility against cipher-suites that we might add in the future. Current spec requires both the encoder and decoder to adjust the position of IV if the payload length is below 4. The proposed change concentrates the adjustment into one point; i.e. when encoder builds the payload.

FWIW, for the cipher-suites that are defined now, the right-hand side of the expression (i.e. `4 + length(iv) - length(aead tag)`) is always 4, which makes the equation exactly the same as what @DavidSchinazi suggests.

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Nov 2018 19:27:57 -0800

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

Is that true? Isn't the length of the packet number field encoded in the first byte?

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 16 Nov 2018 19:29:03 -0800

@DavidSchinazi 
> I would be inclined to disallow TLS_AES_128_CCM_8_SHA256 in QUIC but either way padding the payload is a viable solution

Yeah my point is that I would rather avoid the possibility of discussing _how_ QUIC should be adjusted to support cipher-suites like AES128-CCM8, and that requiring the encoder to pad is a good approach in that respect. Because people who wants to introduce that type of cipher can simply define a different constant for the right-hand side (see my comment 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_r234394744

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 14:47:04 -0800

6e24096  Input to ChaCha20 is five zeros.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/b40e506d9c905f6a8073849d10cc43fd3248f8dd..6e24096c683e6aad23f4ec10f7d16d8d557cec7b

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 14:59:36 -0800

@martinthomson pushed 4 commits.

5b49645  Unused mask bytes
7e74188  Explain initial header protection
c7ef43a  Duplicate sample calculations
d9e063c  Payload length confusion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/6e24096c683e6aad23f4ec10f7d16d8d557cec7b..d9e063c4f52623b364b137331fffdbc5b5f55ccb

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 14:59:46 -0800

Thanks for the feedback everyone.

I considered this, but the fact is that we also protect the header, so payload is equally misleading, perhaps more so.

+

We can't encrypt this value.

We don't explain what `^` means either.

Please take this discussion to an issue.  This will be lost here.

-Long Packet Type:
+Fixed Bit:
+

Not quite the same way.  This can be detected using public information, so you don't need to run a constant-time decryption on that packet.

Right, and this is covered in the -tls doc: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#pn-encrypt-analysis

  0                   1                   2                   3

Saving a byte is neither here nor there, but the two blocks of four unused bits was a problem.  I agree, it's odd :)

-Third Bit:

@DavidSchinazi, we're not doing this for you, but I'm glad you're happy.

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

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Nov 2018 16:32:20 -0800

but ^ isn't ambiguous to those who know about it (which is like everyone)

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 16:57:23 -0800

9526663  Bytes, for consistency

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/d9e063c4f52623b364b137331fffdbc5b5f55ccb..9526663fa427eab01215a3c876898639d8872dff

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Nov 2018 18:27:30 -0800

kazuho requested changes on this pull request.

As noted on https://github.com/quicwg/base-drafts/pull/2006#issuecomment-439259022 (sorry for not making it a review comment), I think you need to change the definition of Stateless Reset.

It currently says:
```
 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|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Random Bytes (160..)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
```

IIUC, this needs to be something like below (though, I am not sure if the spin bit needs to be random in this case).
```
 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|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Random Bits (166..)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
```

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 18:42:26 -0800

00c571e  Fix stateless reset too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/9526663fa427eab01215a3c876898639d8872dff..00c571ec5e9cc3c38668960f95dd9e96c8ca0a42

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Nov 2018 19:05:11 -0800

> @@ -2271,8 +2269,8 @@ following layout:
 This design ensures that a stateless reset packet is - to the extent possible -
 indistinguishable from a regular packet with a short header.
 
-The message consists of a header byte, followed by an arbitrary number of random
-bytes, followed by a Stateless Reset Token.
+The message consists of the first two fixed bits of the packet header, followed
+by an arbitrary number of random bytes, followed by a Stateless Reset Token.

Would it make sense to state like "followed by six (6) bits plus an arbitrary number of bytes in random"?

The fear I have with the current text is that it might imply that Stateless Reset Token starts at the 2 + 8n bit of the packet.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 19:17:40 -0800

53d5d79  2+8n is unlikely, but I've met some of the people implementing this

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/00c571ec5e9cc3c38668960f95dd9e96c8ca0a42..53d5d79f26edab653b945cb496e28001cb9c00f9

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Nov 2018 19:22:12 -0800

kazuho approved this pull request.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 08:33:19 -0800

igorlord commented on this pull request.

What important purpose is served by requiring the value of these bits to be 0?  This precludes the use of these bits for experimental purposes, like VEC and LOSS detection.

Before the use of these bits is standardized, the risk of middleboxes ossifying occasional experimental use of the bits seems less significant than the loss of opportunity to experiment.

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

---

From: ianswett <[email-masked]>
Date: Mon, 19 Nov 2018 08:35:56 -0800

They're set to 0 prior to protection, which means a middlebox can't use them anyway unless you share the header protection key with it.

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Nov 2018 09:11:01 -0800

Suppose that two parties negotiate experimentation with error detection, using either version negotiation or transport parameters. The only requirement would be to set the VEC or ERR bits after packet header protection when sending, and to reset them to zero just before AEAD decryption when receiving. You could specify that as part of the negotiation.

-- 
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#issuecomment-439969490

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 09:11:51 -0800

The header protection is an XOR with a mask.  Setting these bits to a desired experimental value _after_ the header protection is applied (after XOR) works ok, if the other endpoint did not require the bits to be 0 after the header protection is removed.

Hence the question -- why a hard requirement to have these bits 0 after removing header protection, if the endpoint does not use these bits for anything?

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 19 Nov 2018 17:41:07 +0000 (UTC)

MikeBishop commented on this pull request.

Because otherwise they become scratch space where a middlebox could place a persistent marking on the packets.  If peers want to discard integrity checks on some portion of the data they send/receive, they can certainly do so -- but not unilaterally.  By default, modification of the packet makes the packet invalid.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 10:04:50 -0800

Surely AEAD verification would prevent scratch spaces regardless of whether the value is checked or not?

But I can see that setting the value to 0 simplifies future extensions or experiments.

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 19 Nov 2018 10:35:25 -0800

That would be #1575 

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 19 Nov 2018 10:43:06 -0800

-Third Bit:

I realize that, but I just wanted to let you know it was important to us (i.e. please let us know if you plan to change this)

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 19 Nov 2018 10:48:16 -0800

-Third Bit:

I agree with @DavidSchinazi.  This is important to us (@litespeedtech) as well.  Please give a heads up should the plans for bit 0x40 change.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 10:48:22 -0800

Right. An AEAD verification would prevent modification by middleboxes -- a desirable property.  Insistence on the value being 0 prevents experimental use for the purposes that do not require two cooperating endpoints (like Loss bit).

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 19 Nov 2018 11:48:52 -0800

I see that as a feature, rather than a bug. We’re making it harder for one endpoint to expose potentially privacy sensitive information to third parties, if its peer isn’t consenting. Of course, we can never fully prevent that, but at least we can make it harder and increase the overhead for that. 

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 13:45:17 -0800

If you want to negotiate a new version, you can assign these bits however you choose in that version.  Or, in this version, you could negotiate an extension that sets these in different ways (though probably only in short headers in practice).  That extension could also decide to remove any encryption.  So yes, you could use the spare bits for a VEC, if both peers agreed that was a good idea.

Until that time, this is protecting those bits the best way we know how.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 22:10:31 +0000 (UTC)

@marten-seemann, as you said, it is impossible to prevent one party from disclosing anything about the connection to any third party. No shenanigans can make a dent in the amount or quality of info disclosed by a determined party. However, this setup can make it harder to troubleshoot network operations (if that involves unilaterally setting these bits for experimentation).

@martinthomson, yes, and the original comment was looking for a clarification of the threat that we are "protecting those bits the best way we know how".  Is it protecting the bits from an endpoint bent on disclosing some private information to a third party?  Or is it protecting from an endpoint accidentally exposing some information while trying to run an experiment (i.e. since one cannot be sure that everyone will run safe experiments, no one is allowed to run experiments unilaterally)? Or is it protecting from a middlebox ossifying some experimental usage of these bits? Or is it protecting from something else?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 14:27:49 -0800

@igorlord I think @marten-seemann is correct here.

If we say that the bits on the wire is hard-coded to zero, the bits face ossification.
If we say that the bits can be anything, it could be used by an endpoint for any purpose without peer's consent (which is a privacy risk as Marten points out).

By saying that the bits will be set to zero (before encryption) and then encrypted, we prevent ossification and also require peer's consent when an endpoint want to use the bit for other purposes.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 22:52:27 +0000 (UTC)

@kazuho, the suggestion is not bits-on-the-wire are 0 (which is an ossification concern).

The suggestion is that bits can be anything and they are AEAD protected but not masked -- just like the latency spin bit.  They could be set randomly or not randomly -- up to the endpoint.  An endpoint can already disclose any and all info to anyone without peer's consent, and these bits are by far not the most convenient mechanism for such disclosures.

Do I understand it correctly that the worry is about an _accidental_ and not a _deliberate_ disclosure?  (I do not think a worry about ossification of some experimental use it warranted, do you?)

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 15:01:09 -0800

@igorlord 
> The suggestion is that bits can be anything and they are AEAD protected but not masked -- just like the latency spin bit.

Thank you for the clarification. I understand that.

> They could be set randomly or not randomly -- up to the endpoint.

That means that most endpoints will be required to set them randomly, at least initially. The issue here is that you need to randomize the bits separately, rather than just relying on header protection to randomize the bits. It is an complication.

> An endpoint can already disclose any and all info to anyone without peer's consent, and these bits are by far not the most convenient mechanism for such disclosures.

If that is the case, why do we need to care about the bits? If the endpoints have an easier way to expose the information, can't they just be randomized using header protection?

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

---

From: Alexandre Ferrieux <[email-masked]>
Date: Mon, 19 Nov 2018 15:19:30 -0800

ferrieux commented on this pull request.

@kazuho 
> That means that endpoints (that do not have a way to "use" the bits) will be required to set them randomly. The issue here is that you need to randomize the bits separately, rather than just relying on header protection to randomize the bits. It is an unnecessary complexity.

A PRNG is already needed for the spin bit's anonimity set, and for its fixed per-conneciton value when not spinning. A tiny increment, then, compared to the weight of version deployment for anybody willing to experiment with these "reserved" (should be called "frozen") bits.

> If that is the case, why do we need to care about the bits? If the endpoints have an easier way to expose the information, can't they just be randomized using header protection?

What Igor means, I think, is that the protection against unilateral disclosure of *anything* is negligible (for one, the endpoint could send unencrypted copies of the entire flow somewhere else). While using the reserved bits (which were designed for exactly this) is clearly the most efficient way for on-path signalling (no overhead ; same-tuple ; sync with flow).

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 15:22:13 -0800

@kazuho
> If that is the case, why do we need to care about the bits? If the endpoints have an easier way to expose the information, can't they just be randomized using header protection?

An endpoint _deliberately_ trying to compromise the connection's privacy can do it easily (and will likely use a more structured info channel for that purpose). However, an endpoint that is _not_ trying to leak information and is just tagging packets for VEC or Loss detection or other operational purpose would find these bits a lot more convenient.  That said, I understand the concern about some inadvertent disclosure by a poorly designed experiment (if this is the concern).

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 16:21:17 -0800

@ferrieux
> A PRNG is already needed for the spin bit's anonimity set, and for its fixed per-conneciton value when not spinning. A tiny increment, then, compared to the weight of version deployment for anybody…

Runtime overhead is the issue here; I do not think requiring endpoints to call CSPRNG for every packet they send is a good idea (note: use of non-cryptographically secure RNG is a way to leak PN). Re providing the freedom to "experiment", please see my comment below.

> While using the reserved bits (which were designed for exactly this) is clearly the most efficient way for on-path signalling (no overhead ; same-tuple ; sync with flow).

While I do not think reserved bits are "designed" for on-path signaling, I agree that it is a convenient way for exposing signals.

The trade-off here is if we want to pay the extra cost of calling CSPRNG for every packet we send, to provide the endpoints to use the bits exposing information to on-path devices without peers' consent.

@igorlord
> However, an endpoint that is not trying to leak information and is just tagging packets for VEC or Loss detection or other operational purpose would find these bits a lot more convenient. That said, I understand the concern about some inadvertent disclosure by a poorly designed experiment (if this is the concern).

Yes. That is exactly the concern. Remember that we were uncertain about the privacy concerns of the spin bit for very long time (IIRC the risk of exposing the latency of the hidden path behind a VPN was brought up pretty recently).

I think that we should allow endpoints to use the bits for exposing information only when  extensive privacy analysis has been done and the WG is convinced. Protecting the bits under header protection is the easiest way to guarantee that.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 17:23:59 -0800

@kazuho 
> > I understand the concern about some inadvertent disclosure by a poorly designed experiment (if this is the concern).
> 

The extensive analysis of a _specific_ protocol behavior prescribed by a standard was well-advised, indeed. It allowed people to make an informed decision of whether to implement that specific behavior, and different implementers will choose differently.

> I think that we should allow endpoints to use the bits for exposing information only when extensive privacy analysis has been done and the WG is convinced.

Since there is no question about any specific standard purpose to consider for these bits, this concern looks different to me.  It is rather akin to "do not touch anything not approved by us -- the WG -- or you may leak something". There are plenty of ways a sender can "leak something" to the path: IP ID field / IPv6 Flow Label selection, TTL/HopLimit fields, DS/ECN fields, packet size choices, packet timings, congestion avoidance behaviors, etc.  In this light, "we do not trust you with _these_ bits" seems more effective at complicating operational experimentation than at protecting privacy.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 17:29:00 -0800

@igorlord, I've lost track of your thread here.  Are you asking for a specific change?

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 17:30:15 -0800

I do not have experience operating a network with completely opaque traffic.  So it is very possible that experiments with these bits would not materialize even if the bits were available for experimentation.  On the other hand, it is possible that some experiments could prove valuable to operators and not be a privacy threat.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 17:34:22 -0800

To be clear, if client and server both agree to another use for these bits, they can be used for any purpose.  It's only unilateral experimentation that is prevented by the current arrangement, which - as other have said - is intentional.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 17:35:21 -0800

@martinthomson 
Sorry, the thread did get too unwieldy, indeed.  The specific change:

> The suggestion is that reserved bits can be anything and they are AEAD protected but not masked -- just like the latency spin bit.  If not in-use for a specific purpose by the sender, the bits should be randomized.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 17:36:59 -0800

Ack, thanks.

I'd suggest that you take this to the mailing list, and open an issue.  This is one of the worst possible venues for a discussion of this type.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 17:40:33 -0800

Ack. an issue for this makes sense,

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

---

From: janaiyengar <[email-masked]>
Date: Mon, 19 Nov 2018 17:45:35 -0800

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

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.

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?

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

@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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 17:52:49 -0800

Agrees to @janaiyengar that this is a separate issue. FWIW, the relevant issues are #1575 (simplification) and #2019 (support for AES128-CCM8, or possibly other cipher-suites using shorter tags).

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 17:54:10 -0800

>  How do we counter that?

@janaiyengar as I wrote in an earlier comment, the fields are protected as authenticated data in the AEAD tag, so middleboxes cannot change the bits without getting the packet rejected. At best they can read the bits iff they are outside header protection, but they are not.

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

---

From: janaiyengar <[email-masked]>
Date: Mon, 19 Nov 2018 17:58:07 -0800

@mikkelfj : *facepalm* Right.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 18:04:23 -0800

Opened issue #2022.

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Nov 2018 18:07:37 -0800

I think the spec is right. In the absence of standard, the use case for VEC or ERR in V1 cannot be "manage my network". De facto, it has to be "experiment with new algorithms that would let me manage my network better". And experimenters can in fact do that, if clients and servers cooperate.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 15:07:23 -0800

a89f732  Merge branch 'master' into first-octet

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006/files/53d5d79f26edab653b945cb496e28001cb9c00f9..a89f732c21eacaa2cbd3c0d4f3145128afa47083

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 15:08:02 -0800

Merged #2006 into master.

-- 
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#event-1978705573