Subject: [quicwg/base-drafts] Be clearer about protections (#3900)

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Jul 2020 23:27:21 -0700

This breaks down some of the packet protection text in favour of more
specific language about the protections provided.  By preference,
this talks about integrity protection and confidentiality protection as
it relates to those packets that are protected using keys derived from
TLS.  For Initial packets this means avoid use of &quot;packet protection&quot; as
much as possible (I&#39;m sure that I have missed some of these).  The same
for Retry.

This required some additional framing, but it wasn&#39;t too intrusive.
Most of the changes are cosmetic.

(I could maybe have split the exposition about initial secrets from this, but it would mean juggling conflicting changesets.)

Closes #3887.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Be clearer about protections

-- File Changes --

    M draft-ietf-quic-tls.md (75)
    M draft-ietf-quic-transport.md (48)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3900.patch
https://github.com/quicwg/base-drafts/pull/3900.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/3900

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Jul 2020 23:35:13 -0700

@martinthomson pushed 1 commit.

25264d07790fcb63f08d3400a9bb61aa6a4785c2  First initial

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/a38e49b3e25977f9dea8f0bc099e542f04004d5a..25264d07790fcb63f08d3400a9bb61aa6a4785c2

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Jul 2020 07:48:11 -0700

@MikeBishop approved this pull request.

> @@ -895,7 +895,28 @@ keeping track of missing packet numbers.
 # Packet Protection {#packet-protection}
 
 As with TLS over TCP, QUIC protects packets with keys derived from the TLS
-handshake, using the AEAD algorithm negotiated by TLS.
+handshake, using the AEAD algorithm {{!AEAD}} negotiated by TLS.
+
+QUIC packets have varying protections depending on their type:
+
+* Version Negotiation packets have no cryptographic protection.
+
+* Retry packets use AEAD_AES_128_GCM to provide protection against accidental
+  modification or insertion by off-path adversaries; see
+  {{retry-integrity}}.
+
+* Initial packets use AEAD_AES_128_GCM with keys derived from the Destination
+  Connection ID field of the client Initial packet; see {{initial-secrets}}.

```suggestion
  Connection ID field of the first Initial packet sent by the client; see
  {{initial-secrets}}.
```

> @@ -895,7 +895,28 @@ keeping track of missing packet numbers.
 # Packet Protection {#packet-protection}
 
 As with TLS over TCP, QUIC protects packets with keys derived from the TLS
-handshake, using the AEAD algorithm negotiated by TLS.
+handshake, using the AEAD algorithm {{!AEAD}} negotiated by TLS.
+
+QUIC packets have varying protections depending on their type:
+
+* Version Negotiation packets have no cryptographic protection.
+
+* Retry packets use AEAD_AES_128_GCM to provide protection against accidental
+  modification or insertion by off-path adversaries; see
+  {{retry-integrity}}.
+
+* Initial packets use AEAD_AES_128_GCM with keys derived from the Destination
+  Connection ID field of the client Initial packet; see {{initial-secrets}}.

I'm surprised this doesn't mention the properties provided, since the other two bullets do.  The Initial protection provides the same protections that the Retry tag does, plus protection against version-unaware middleboxes.

-- 
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/3900#pullrequestreview-448175295

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 15:49:15 -0700

@martinthomson commented on this pull request.

I put that in the referenced section.  I wasn't sure which way to go.

-- 
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/3900#discussion_r454688996

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 15:49:27 -0700

83e840eb0fdef5f972306477b8b9cc62fe355bb4  first Initial

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/25264d07790fcb63f08d3400a9bb61aa6a4785c2..83e840eb0fdef5f972306477b8b9cc62fe355bb4

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jul 2020 21:04:48 -0700

c78921e5d3ff5d5ea37a398eccd8afd74872e71b  Use text from master for this paragraph

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/5782bf9aead14fee58252a587376e56bf62abf91..c78921e5d3ff5d5ea37a398eccd8afd74872e71b

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jul 2020 21:05:18 -0700

1db24ca405c391ad6044260aeb196626b1c716d3  Trailing whitespace, gah

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/c78921e5d3ff5d5ea37a398eccd8afd74872e71b..1db24ca405c391ad6044260aeb196626b1c716d3

---

From: ianswett <[email-masked]>
Date: Thu, 16 Jul 2020 08:01:55 -0700

@ianswett approved this pull request.

+* Version Negotiation packets have no cryptographic protection.
+
+* Retry packets use AEAD_AES_128_GCM to provide protection against accidental
+  modification or insertion by off-path adversaries; see
+  {{retry-integrity}}.
+
+* Initial packets use AEAD_AES_128_GCM with keys derived from the Destination
+  Connection ID field of the first Initial packet sent by the client; see
+  {{initial-secrets}}.
+
+* All other packets have strong cryptographic protections for confidentiality
+  and integrity, using keys and algorithms negotiated by TLS.
+
+This section describes how packet protection is applied to Handshake packets,
+0-RTT packets, and packets with short headers. The same packet protection

```suggestion
0-RTT packets, and 1-RTT packets with short headers. The same packet 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/3900#pullrequestreview-449934611

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 Jul 2020 18:43:37 -0700

@janaiyengar commented on this pull request.

This is really useful! A few minor comments.

+process is applied to Initial packets. However, as it is trivial to determine
+the keys, Initial packets are not considered to have confidentiality or

```suggestion
the keys used for Initial packets, these packets are not considered to have confidentiality or
```

> @@ -1175,10 +1175,11 @@ discarded if they indicate a different protocol version than that of the
 connection, or if the removal of packet protection is unsuccessful once the
 expected keys are available.
 
-Invalid packets without packet protection, such as Initial, Retry, or Version
-Negotiation, MAY be discarded.  An endpoint MUST generate a connection error if
-processing of the contents of these packets prior to discovering an error
-resulted in changes to the state of a connection that cannot be reverted.
+Invalid packets that lack strong integrity protection, such as Initial, Retry,
+or Version Negotiation, MAY be discarded. An endpoint MUST generate a
+connection error if processing of the contents of these packets prior to

```suggestion
connection error if processing the contents of these packets prior to
```

> @@ -1175,10 +1175,11 @@ discarded if they indicate a different protocol version than that of the
 connection, or if the removal of packet protection is unsuccessful once the
 expected keys are available.
 
-Invalid packets without packet protection, such as Initial, Retry, or Version
-Negotiation, MAY be discarded.  An endpoint MUST generate a connection error if
-processing of the contents of these packets prior to discovering an error
-resulted in changes to the state of a connection that cannot be reverted.
+Invalid packets that lack strong integrity protection, such as Initial, Retry,
+or Version Negotiation, MAY be discarded. An endpoint MUST generate a
+connection error if processing of the contents of these packets prior to
+discovering an error resulted in changes to the state of a connection that

```suggestion
discovering an error resulted in changes to connection state that
```

> @@ -1175,10 +1175,11 @@ discarded if they indicate a different protocol version than that of the
 connection, or if the removal of packet protection is unsuccessful once the
 expected keys are available.
 
-Invalid packets without packet protection, such as Initial, Retry, or Version
-Negotiation, MAY be discarded.  An endpoint MUST generate a connection error if
-processing of the contents of these packets prior to discovering an error
-resulted in changes to the state of a connection that cannot be reverted.
+Invalid packets that lack strong integrity protection, such as Initial, Retry,
+or Version Negotiation, MAY be discarded. An endpoint MUST generate a
+connection error if processing of the contents of these packets prior to

Which error?

> +Retry packets use an authenticated encryption with associated data (AEAD;
+{{?AEAD=RFC5116}}) function to protect against accidental modification.

```suggestion
Retry packets use an authenticated encryption with associated data function
(AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification.
```

> +The Packet Number field that appears in some packet types contains a packet
+number, which has additional confidentiality protection that is applied as part
+of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The
+underlying packet number increases with each packet sent in a given packet
+number space; see {{packet-numbers}} for details.

```suggestion
The Packet Number field that appears in some packet types
has additional confidentiality protection that is applied as part
of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The
underlying packet number increases with each packet sent in a given packet
number space; see {{packet-numbers}} for details.
```

-- 
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/3900#pullrequestreview-450318609

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Jul 2020 19:45:51 -0700

@kazuho commented on this pull request.

:+1: LGTM modulo the points below.

> -Initial packets are protected using keys that are statically derived. This
-packet protection is not effective confidentiality protection.  Initial
-protection only exists to ensure that the sender of the packet is on the network
-path. Any entity that receives the Initial packet from a client can recover the
-keys necessary to remove packet protection or to generate packets that will be
+QUIC packets have different levels of cryptographic protection based on the
+type of packet. Details of packet protection are found in {{QUIC-TLS}}; this
+section includes an overview of the protections that are provided.
+
+Version Negotiation packets have no cryptographic protection; see
+{{QUIC-INVARIANTS}}.
+
+Retry packets use an authenticated encryption with associated data (AEAD;
+{{?AEAD=RFC5116}}) function to protect against accidental modification.
+
+Initial packets use an AEAD with keys that are statically derived. This does

The keys are generated for each connection, so I think it is confusing to use the word "statically" here. Maybe something like:

```suggestion
Initial packets use an AEAD with keys that are derived using a value that is visible on the wire, and therefore does
```

>  successfully authenticated.
 
 All other packets are protected with keys derived from the cryptographic
 handshake. The type of the packet from the long header or key phase from the
 short header are used to identify which encryption keys are used. Packets
-protected with 0-RTT and 1-RTT keys are expected to have confidentiality and
-data origin authentication; the cryptographic handshake ensures that only the
+protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality
+and integrity protection; the cryptographic handshake ensures that only the

Maybe "authentication, confidentiality, and integrity protection"? I think that would be more consistent with the use of terms thatwe see in RFC 8446 section 1.

-- 
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/3900#pullrequestreview-450338268

---

From: Marten Seemann <[email-masked]>
Date: Thu, 16 Jul 2020 19:52:07 -0700

@marten-seemann commented on this pull request.

"1-RTT packets with short headers" implies that there's another kind of 1-RTT packets.

-- 
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/3900#discussion_r456189357

---

From: ianswett <[email-masked]>
Date: Fri, 17 Jul 2020 06:33:53 -0700

@ianswett commented on this pull request.

Fair, but it seems odd to me to talk about the header length and not mention the keys being used.

-- 
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/3900#discussion_r456444805

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Jul 2020 16:34:58 -0700

05cb8f2eb7027a63f4697fccec69a18f194a405b  Lots of review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/1db24ca405c391ad6044260aeb196626b1c716d3..05cb8f2eb7027a63f4697fccec69a18f194a405b

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Jul 2020 16:36:44 -0700

bca2743083bca2e8a7b85abb392b85675798c8fe  wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/05cb8f2eb7027a63f4697fccec69a18f194a405b..bca2743083bca2e8a7b85abb392b85675798c8fe

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Jul 2020 19:49:56 -0700

Those are inclusive of other properties provided by TLS, so the packet protection doesn't strictly provide authentication in the same way.

-- 
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/3900#discussion_r457000832

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 19 Jul 2020 23:25:26 -0700

I'm not against viewing that way, though then I think it might be better to talk about 0-RTT, Handshake and 1-RTT packets, rather than just 0-RTT and 1-RTT packets.

It might be a good idea to change the first sentence of the paragraph to the following and remove the last sentence: _All other packets are expected to provide strong confidentiality and integrity protection using the keys derived from the cryptograph handshake; the handshake ensures that only the communicating endpoints receive the corresponding keys._

-- 
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/3900#discussion_r457091560

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 20 Jul 2020 19:17:05 -0700

a few nits

>  The connection ID used with HKDF-Expand-Label is the Destination Connection ID
 in the Initial packet sent by the client.  This will be a randomly-selected
 value unless the client creates the Initial packet after receiving a Retry
 packet, where the Destination Connection ID is selected by the server.
 
-The value of initial_salt is a 20-byte sequence shown in the figure in
-hexadecimal notation. Future versions of QUIC SHOULD generate a new salt value,
-thus ensuring that the keys are different for each version of QUIC. This
-prevents a middlebox that only recognizes one version of QUIC from seeing or
-modifying the contents of packets from future versions.
+Future versions of QUIC SHOULD generate a new salt value, thus ensuring that
+the keys are different for each version of QUIC.  This prevents a middlebox that
+only recognizes one version of QUIC from seeing or modifying the contents of

```suggestion
recognizes only one version of QUIC from seeing or modifying the contents of
```

> +Initial packets use an AEAD with keys that are derived using a value that is
+visible on the wire, and therefore does not provide effective confidentiality
+protection. Initial protection exists to ensure that the sender of the packet is

A bit of a run-on sentence here. Maybe: "Initial packets use an AEAD, the keys for which are derived using a value that is visible on the wire. The AEAD for Initial packets therefore does not provide effective ..."

-packet protection is not effective confidentiality protection.  Initial
-protection only exists to ensure that the sender of the packet is on the network
-path. Any entity that receives the Initial packet from a client can recover the
-keys necessary to remove packet protection or to generate packets that will be
-successfully authenticated.
+Version Negotiation packets have no cryptographic protection; see
+{{QUIC-INVARIANTS}}.
+
+Retry packets use an authenticated encryption with associated data function
+(AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification.
+
+Initial packets use an AEAD with keys that are derived using a value that is
+visible on the wire, and therefore does not provide effective confidentiality
+protection. Initial protection exists to ensure that the sender of the packet is
+on the network path. Any entity that receives the Initial packet from a client

```suggestion
on the network path. Any entity that receives an Initial packet from a client
```

> +can recover the keys that will allow them to read the contents of packets or
+generate packets that will be successfully authenticated.

```suggestion
can recover the keys that will allow them to both read the contents of the packet
and generate Initial packets that will be successfully authenticated at either
endpoint.
```

-- 
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/3900#pullrequestreview-452077287

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2020 02:49:16 -0700

92d1701ac1e5b1554dc1df4abf0c7af3a5b0d403  Moor sugestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/bca2743083bca2e8a7b85abb392b85675798c8fe..92d1701ac1e5b1554dc1df4abf0c7af3a5b0d403

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2020 02:50:51 -0700

@martinthomson pushed 3 commits.

00d90fccb3fb8dfb3e831198629a63b0399052ad  Some more rearrangement
645d6f8be9824db6909f2a02131c21a690a30809  Cleaner
7f190d7ec7885c46bc0a4e40a3535870af006b6d  Split sentence; reword

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3900/files/92d1701ac1e5b1554dc1df4abf0c7af3a5b0d403..7f190d7ec7885c46bc0a4e40a3535870af006b6d