Subject: [quicwg/base-drafts] Tweak the split between quic-transport and quic-tls drafts (#4138)

From: David Schinazi <[email-masked]>
Date: Tue, 22 Sep 2020 18:43:44 -0700

This PR moves non-TLS-specific text from quic-tls to quic-transport to facilitate designing future versions of QUIC that use different cryptographic handshake protocols.

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

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

-- Commit Summary --

  * Tweak the split between quic-transport and quic-tls drafts

-- File Changes --

    M draft-ietf-quic-tls.md (1258)
    M draft-ietf-quic-transport.md (1286)

-- Patch Links --

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 Sep 2020 20:55:21 -0700

@huitema commented on this pull request.

I worked on PR #4136 with @martinthomson . It might be better to leave section 4 alone of TLS alone in this PR, and avoid having to reconcile later.

> +  appear in any packet number space. CONNECTION_CLOSE frames signaling
+  application errors (type 0x1d) MUST only appear in the application data packet
+  number space.
+
+- ACK frames MAY appear in any packet number space, but can only acknowledge
+  packets that appeared in that packet number space.  However, as noted below,
+  0-RTT packets cannot contain ACK frames.
+
+- All other frame types MUST only be sent in the application data packet number
+  space.
+
+Note that all frames can appear in 1-RTT packets.  Note that it is not possible
+to send the following frames in 0-RTT packets for various reasons: ACK, CRYPTO,
+HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and RETIRE_CONNECTION_ID. An endpoint
+MUST treat receipt of a frame in a packet type that is not permitted as a
+connection error of type PROTOCOL_VIOLATION.

This will need to be reconciled with PR #4136, which does not copy the text at this location and updates references. It might be more expedient to not do this change and not modify Section 4 of TLS is this Pr (4138).

> -  application errors (type 0x1d) MUST only appear in the application data packet
-  number space.
-
-- ACK frames MAY appear in any packet number space, but can only acknowledge
-  packets that appeared in that packet number space.  However, as noted below,
-  0-RTT packets cannot contain ACK frames.
-
-- All other frame types MUST only be sent in the application data packet number
-  space.
-
-Note that it is not possible to send the following frames in 0-RTT packets for
-various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and
-RETIRE_CONNECTION_ID.  A server MAY treat receipt of these frames in 0-RTT
-packets as a connection error of type PROTOCOL_VIOLATION.
+into the same packet. Note that some frames are prohibited in different packet
+number spaces, as described in Section 12.4 of {{QUIC-TRANSPORT}}.

Same remark, this conflicts with the work in PR #4136. Probably better to leave this alone.

-- 
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/4138#pullrequestreview-494009828

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Sep 2020 23:45:43 -0700

@martinthomson commented on this pull request.

I'm guessing, but it looks like you just went through the TLS draft and identified sections that you think belong in transport and moved them across as you went.  Then you fixed references (I found a few that you missed, but I only looked at the diff for that, there might be others).

What makes this hard is that it is the stuff that isn't moved or changed that is hardest to reason about.

The net effect of this would be a much longer transport draft and a much shorter TLS one.  I don't have major objections to that, but this approach requires that we think very carefully about how to structure the landing of the new pieces, and what your split was.

I assume that minimal text changed around as it was moved, other than to correct references, I'm looking mostly at structural things.

Section 1.1 of the transport draft need some fairly significant surgery to deal with the addition of new top-level sections.  This adds sections on packet protection, key update, and ¯\(°_o)/¯ to that list.

I wonder whether your placement of this text fits though.  We might want to define packet formats before we get into the details of packet protection.  Or we might want to think about whether there are conceptual-level items that could go in earlier sections (Section 12 seems like it might benefit from some text on packet protection and key update) with details deferred to later sections.

The main thing I question is the shape of the split.

The big question here is whether TLS provides secrets or keys?

You have included initial secret calculation as part of the moved text.  However, you left the details of calculating packet protection keys from secrets in the TLS draft. As well as the updating the secrets during key update.  And the TLS draft still includes the packet protection examples.  I don't understand this particular division.

Of course, if you move the handling of secrets, then there are other pieces of text that move also.  I'm looking at Key Diversity from the Security Considerations section.

Some of the text regarding 0-RTT might move as well.  The security considerations moved, but most of the text about enabling it and deciding whether to use it didn't cross over at the same time. Though there are some TLS-specific details, most of that is not dependent on a particular AKE protocol.  You could lump 0.5-RTT in with that if you are talking about stuff that is sent before the handshake completes.  Of course, though 0-RTT is a QUIC-specific label, it's a concept that is TLS-specific in an awkward way.

I somewhat expected you to move the definition of Handshake Complete and Handshake Confirmed as well.  These could be defined based on an abstract definition of "cryptographic handshake".

All of this is to say that the ultimate result of this process is a single document unless we have a clean logical separation point on which we can draw the line.  So maybe I should ask, what do you think that line is?

Minor stuff includes a lack of section numbers in the new cross-document references.  I haven't grepped for references to sections >= 17 in the recovery or http drafts, but it might be worth checking.

This is not as bad as I feared.  I thought that you would attempt to more cleanly define an abstract split between the two pieces, which would have been like the attempt to abstract out UDP.  That is something I would oppose.  I'm not sure if this has completely avoided heading in that direction.  To the extent that it has avoided that, it's not bad.

I still don't like this change much, but mostly because it is very disruptive.

> +Due to reordering and loss, protected packets might be received by an endpoint
+before the handshake is complete (see {{QUIC-TLS}}).  A client will be unable to
+decrypt 1-RTT packets from the server, whereas a server will be able to decrypt
+1-RTT packets from the client.  Endpoints in either role MUST NOT decrypt 1-RTT
+packets from their peer prior to completing the handshake.
+
+Even though 1-RTT keys are available to a server after receiving the first
+handshake messages from a client, it is missing assurances on the client state:
+
+- The client is not authenticated, unless the server has chosen to use a
+  pre-shared key and validated the client's pre-shared key binder; see Section
+  4.2.11 of {{!TLS13}}.
+
+- The client has not demonstrated liveness, unless the server has validated the
+  client's address with a Retry packet or other means; see Section 8.1 of
+  [QUIC-TRANSPORT].

self-citation

> +packets coalesced with a Handshake packet containing a copy of the CRYPTO frame
+that carries handshake messages, until one of the Handshake packets is
+acknowledged.  This enables immediate server processing for those packets.
+
+A server could receive packets protected with 0-RTT keys prior to receiving the
+handshake messages it'll need to decrypt them.  The server MAY retain these
+packets for later decryption in anticipation of receiving those messages.
+
+A client generally receives 1-RTT keys at the same time as the handshake
+completes.  Even if it has 1-RTT secrets, a client MUST NOT process
+incoming 1-RTT protected packets before the handshake is complete.
+
+
+# Key Update
+
+Once the handshake is confirmed (see {{QUIC-TLS}}), an endpoint MAY initiate a

Needs a section number.

> +  limits on TLS record size. The maximum size of a TLS record is 2^14 bytes.
+  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is
+  expected that QUIC packets will generally be smaller than TLS records.
+  Where packets might be larger than 2^14 bytes in length, smaller limits might
+  be needed.
+
+Any TLS cipher suite that is specified for use with QUIC MUST define limits on
+the use of the associated AEAD function that preserves margins for
+confidentiality and integrity. That is, limits MUST be specified for the number
+of packets that can be authenticated and for the number of packets that can fail
+authentication.  Providing a reference to any analysis upon which values are
+based - and any assumptions used in that analysis - allows limits to be adapted
+to varying usage conditions.
+
+
+# Security of Initial Messages

As a top-level heading, this is odd.  It also only has one child at the next level, which I use as an indication that something is off.  This is a stand-alone top-level section in the TLS doc right now, but it probably needs to move to security considerations even if none of the rest of this moves.

> +of tampering -- such as modifying the handshake messages themselves -- may be
+detectable, but some -- such as modifying ACKs -- are not.
+
+For example, an attacker could inject a packet containing an ACK frame that
+makes it appear that a packet had not been received or to create a false
+impression of the state of the connection (e.g., by modifying the ACK Delay).
+Note that such a packet could cause a legitimate packet to be dropped as a
+duplicate.  Implementations SHOULD use caution in relying on any data that is
+contained in Initial packets that is not otherwise authenticated.
+
+It is also possible for the attacker to tamper with data that is carried in
+Handshake packets, but because that tampering requires modifying handshake
+messages, that tampering will cause the TLS handshake to fail.
+
+
+## Discarding Unused Keys

Check placement; this seems like it needs a new home, but I don't have one.  It certainly doesn't belong here.

It might go in Section 7 (Handshake), but it draws on a bunch of context that isn't introduced until much later.  This is hard to place properly.

+The successful use of Handshake packets indicates that no more Initial packets
+need to be exchanged, as these keys can only be produced after receiving all
+CRYPTO frames from Initial packets.  Thus, a client MUST discard Initial keys
+when it first sends a Handshake packet and a server MUST discard Initial keys
+when it first successfully processes a Handshake packet.  Endpoints MUST NOT
+send Initial packets after this point.
+
+This results in abandoning loss recovery state for the Initial encryption level
+and ignoring any outstanding Initial packets.
+
+
+### Discarding Handshake Keys
+
+An endpoint MUST discard its handshake keys when the handshake is confirmed
+(see {{QUIC-TLS}}).  The server MUST send a HANDSHAKE_DONE frame as soon

Citations of this form should look like "blah blah; see X." at the end of sentences (which is where we try to ensure they end up), parentheticals only mid-sentence or if they match other parentheticals, such as "this applies to X (see X) or Y (see Y)."

> @@ -4850,6 +5697,61 @@ MUST treat a failed validation as a connection error of type
 PROTOCOL_VIOLATION.

+#### Retry Packet Integrity {#retry-integrity}

A painful reminder that Retry is one of the few sections that uses a fourth-level heading, but I can't fault this placement.

-Ultimately, the responsibility for managing the risks of replay attacks with
-0-RTT lies with an application protocol.  An application protocol that uses QUIC
-MUST describe how the protocol uses 0-RTT and the measures that are employed to
-protect against replay attack.  An analysis of replay risk needs to consider
-all QUIC protocol features that carry application semantics.
-
-Disabling 0-RTT entirely is the most effective defense against replay attack.
-
-QUIC extensions MUST describe how replay attacks affect their operation, or
-prohibit their use in 0-RTT.  Application protocols MUST either prohibit the use
-of extensions that carry application semantics in 0-RTT or provide replay
-mitigation strategies.
-
-
-## Packet Reflection Attack Mitigation {#reflection}

I think that this section should move across, even if we don't move more stuff.  The DoS stuff mostly lives in the transport draft anyway.

> +An endpoint is not expected to handle key updates when it is closing
+({{key-update}}). A key update might prevent the endpoint from moving from the

```suggestion
An endpoint is not expected to handle key updates when it is closing; see
{{key-update}}. A key update might prevent the endpoint from moving from the
```

> +which case the byte sequence is interpreted as a little-endian value.
+
+The remaining 12 bytes are used as the nonce. A ChaCha20 implementation might
+take an array of three 32-bit integers in place of a byte sequence, in which
+case the nonce bytes are interpreted as a sequence of 32-bit little-endian
+integers.
+
+The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes. In
+pseudocode:
+
+~~~
+counter = sample[0..3]
+nonce = sample[4..15]
+mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})
+~~~
+

```suggestion
```

> +Once a client has installed 1-RTT keys, it MUST NOT send any more 0-RTT
+packets.
+
+Note:
+
+: 0-RTT data can be acknowledged by the server as it receives it, but any
+  packets containing acknowledgments of 0-RTT data cannot have packet protection
+  removed by the client until the handshake is complete.  The 1-RTT keys
+  necessary to remove packet protection cannot be derived until the client
+  receives all server handshake messages.
+
+
+## Receiving Out-of-Order Protected Packets {#pre-hs-protected}
+
+Due to reordering and loss, protected packets might be received by an endpoint
+before the handshake is complete (see {{QUIC-TLS}}).  A client will be unable to

```suggestion
before the handshake is complete; see Section ?? of {{QUIC-TLS}}.  A client will be unable to
```

-  number space.
-

As Christian says, we've got this already.

-- 
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/4138#pullrequestreview-494181747

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Sep 2020 15:28:31 +0000 (UTC)

@DavidSchinazi commented on this pull request.

-  number space.
-

You've got it already, in a non-merged PR. If that PR is merged before this one then I'll resolve the merge conflict.

-- 
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/4138#discussion_r493686355

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Sep 2020 08:29:19 -0700

I'll resolve merge conflicts as they arise, if that PR lands first I'll look at the exact text that was merged and make sure this PR is updated to reflect 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/4138#discussion_r493686966

---

From: David Schinazi <[email-masked]>
Date: Wed, 23 Sep 2020 15:39:06 +0000 (UTC)

@martinthomson My thought process was to say that the cryptographic handshake protocol is responsible for providing keys (not secrets). This matches the "QUIC and TLS Interactions" diagram that's already in the spec. And it'll allow more flexibility to future handshake protocols.

My thought was that TRANSPORT handles how to use the keys (packet protection, when and how to signal key update) whereas TLS handles how to generate these keys, and drop old ones. Similarly, TRANSPORT has actions that react to handshake completion/confirmation, but TLS defines when that happens.

I did have some decisions points where I wasn't sure, so happy to discuss and revisit those:
- initial secrets, right now I moved them TRANSPORT since that can be implemented without TLS, but it does bring in HKDF which is TLS-y
- 0-RTT was tricky, ideally I thought that it's a TRANSPORT concept apart from getting the keys from TLS, but that one is slightly awkward

I definitely missed some cross-references, I'll do a more thorough pass if/when we reach consensus on the overall shape of this PR.

I agree that this is slightly disruptive, and for that I apologize. But I really think that there should be an appetite for editorial changes now that we've resolved almost every single design issue.

-- 
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/4138#issuecomment-697560212

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Sep 2020 20:26:28 +0000 (UTC)

I am not sure that I agree with the reasoning that "that TRANSPORT handles how to use the keys (packet protection, when and how to signal key update) whereas TLS handles how to generate these keys, and drop old ones. Similarly, TRANSPORT has actions that react to handshake completion/confirmation, but TLS defines when that happens." That seems a very disruptive change. In practice, I did not find it hard to go read the TLS document to implement key derivation, etc. I think the proposed change goes significantly too far.

The criteria for me ought to be about expertise. The TLS document carries expertise on a cryptographic issues, so the specifications that rely on such expertise should stay there.

-- 
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/4138#issuecomment-697953810

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Sep 2020 23:53:38 -0700

@DavidSchinazi,

> the cryptographic handshake protocol is responsible for providing keys (not secrets)

This certainly isn't how our implementation operates, and it isn't how I think of the key schedule.  The place that I think decides this is key updates, where it is QUIC specifications that signal updates and manage the rollover of secrets.

Following that logic, you can make a good case for the initial secrets being in either place.  Either because you don't rely on the cryptographic handshake protocol to provide them and QUIC fills the gap, or because you assume that the cryptographic handshake protocol does provide them and the current TLS mapping does a poor job of providing secrets that are actually secret.  (This latter argument flows from the design of Christian and Kazuho's work on encrypting Initial packets with ECH-derived keys.)

> I agree that this is slightly disruptive, and for that I apologize. 

Don't apologize.  It's an unavoidable consequence of this being lots of work.  And of the fact that the documents have never really been stable enough to do it sooner.  Based on what I'm seeing, I'm still leaning toward Christian's viewpoint on this.  The current split has drawbacks, but it has the virtue of bundling all the crypto stuff together and that is a division that is easy to comprehend.

-- 
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/4138#issuecomment-698152832

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Sep 2020 16:03:39 -0700

Closing based on issue comments.

-- 
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/4138#issuecomment-698631487

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Sep 2020 16:03:41 -0700

Closed #4138.

-- 
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/4138#event-3805387019