Subject: [quicwg/base-drafts] Stream0 dt output ready (#1377)

From: ekr <[email-masked]>
Date: Tue, 22 May 2018 18:26:01 -0700

This is the output of the Stream 0 Design Team.

A high-level description and rationale for the proposal can be found at:
https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit?ts=5b04c125
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Output of Stream 0 Design Team.
  * Fix changelog

-- File Changes --

    M draft-ietf-quic-recovery.md (203)
    M draft-ietf-quic-tls.md (1432)
    M draft-ietf-quic-transport.md (711)

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 22 May 2018 19:03:49 -0700

mikkelfj commented on this pull request.

> @@ -130,15 +145,15 @@ number for transmissions, and any data that is to be delivered to the receiving
 application(s) is sent in one or more streams, with delivery order determined
 by stream offsets encoded within STREAM frames.
 
-QUIC's packet number is strictly increasing, and directly encodes transmission
-order.  A higher QUIC packet number signifies that the packet was sent later,
-and a lower QUIC packet number signifies that the packet was sent earlier.  When
-a packet containing frames is deemed lost, QUIC rebundles necessary frames in a
-new packet with a new packet number, removing ambiguity about which packet is
-acknowledged when an ACK is received.  Consequently, more accurate RTT
-measurements can be made, spurious retransmissions are trivially detected, and
-mechanisms such as Fast Retransmit can be applied universally, based only on
-packet number.
+QUIC's packet number is strictly increasing within a packet number space,
+and directly encodes transmission order.  A higher QUIC packet number signifies
+that the packet was sent later, and a lower QUIC packet number signifies that
+the packet was sent earlier.  When a packet containing frames is deemed lost,
+QUIC rebundles necessary frames in a new packet with a new packet number,
+removing ambiguity about which packet is acknowledged when an ACK is received.

This appears as if frames are copied into new packets, but it is content or latest status that is sent upon loss detection.

-- 
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/1377#pullrequestreview-122411937

---

From: ekr <[email-masked]>
Date: Tue, 22 May 2018 19:11:32 -0700

@ekr pushed 1 commit.

1a30fc6  Fix whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1377/files/9ffd3f1ad47f271685f83a9ca831d321eb1373dd..1a30fc610114e15c254b623df188fd858d9518a5

---

From: ekr <[email-masked]>
Date: Tue, 22 May 2018 20:13:06 -0700

@ekr pushed 1 commit.

c0d3cbc  Offset and length fields in CRYPTO_HS are not optional

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 May 2018 00:47:23 -0700

> +
+When an endpoint receives a packet containing a CRYPTO_HS frame from
+the network, it proceeds as follows:
+
+- If the packet was in the current receiving encryption level, sequence
+  the data into the input flow as usual. As with STREAM frames,
+  the offset is used to find the proper location in the data sequence.
+  If the result of this process is that new data is available, then
+  it is delivered to TLS.
+
+- If the packet is from a previously installed encryption level, it
+  MUST not contain data which extends past the end of previously
+  received data in that flow. [TODO(ekr): Double check that this
+  can't happen]. Implementations MUST treat any violations of this
+  requirement as a connection error of type PROTOCOL_VIOLATION.
+

Please clarify if this is at UDP datagram level or QUIC packet level since datagrams can contain multiple QUIC 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/1377#pullrequestreview-122466454

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 May 2018 01:06:54 -0700

-The payload of an Initial packet conveys a STREAM frame (or frames) for stream
-0 containing a cryptographic handshake message.  The stream in this packet
-always starts at an offset of 0 (see {{stateless-retry}}) and the complete
-cryptographic handshake message MUST fit in a single packet (see {{handshake}}).
+The first Initial packet contains a packet number of 0. Each packet sent after
+the Initial packet is associated with a packet number space and its packet
+number increases monotonically in that space (see {{packet-numbers}}).
+

It appears as if the initial packet is not part of a number space so a second packet could start from 0 or a random base and increment from 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/1377#pullrequestreview-122472389

---

From: ekr <[email-masked]>
Date: Wed, 23 May 2018 06:01:28 -0700

@ekr pushed 2 commits.

66350c8  Remove smart quotes
c38e7ee  Merge pull request #30 from quicwg/stream0

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1377/files/c0d3cbc47732deab4c3148255c0b0ca43cbacb5c..c38e7eedc9d0aa88ef68d0213f29560e4aa802bb

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 07:24:57 -0700

kazuho commented on this pull request.

> +been delivered to QUIC, it is QUIC's responsibility to deliver it
+reliably. Each chunk of data is associated with the then-current TLS
+sending keys, and if QUIC needs to retransmit that data, it MUST use
+the same keys even if TLS has already updated to newer keys.
+
+One important difference between TLS 1.3 records (used with TCP)
+and QUIC CRYPTO_HS frames is that in QUIC multiple frames may appear
+in the same QUIC packet as long as they are associated with the
+same encryption level. For instance, an implementation might
+bundle a Handshake message and an ACK for some Handshake
+data into the same packet.
+
+In general, the rules for which data can appear in packets of which
+encryption level are the same in QUIC as in TLS over TCP:
+
+- CRYPTO_HS frames MAY appear in packets of any encryption level.

The text suggests that a CRYPTO_HS frame might appear in a 0-RTT packet. I think we need to forbid that.

IMO, the only handshake message that might make sense to show up in a 0-RTT packet is EndOfEarlyData. However, allowing that introduces unnecessary complexity.

We need to deliver the TLS messages to the TLS stack in the order they were issued.

A QUIC implementation can easily guarantee that plaintext messages (i.e. CH, SH) carried over the Initial packets will be delivered prior to handshake messages carried over the Handshake packets (e.g., EE, Certificate, Finished), because the latter cannot be decrypted without the former being delivered. The same argument goes for NST being delivered after ServerFinished.

If we send EOED using a Handshake packet, we will continue to have the in-order delivery guarantee.

OTOH, if we send EOED using a 0-RTT packet, QUIC stacks will be required to reassembly the input across multiple encryption levels, i.e., delay passing the payload of CRYPTO_HS frames found in Handshake packets until receiving a 0-RTT packet containing a EOED message. Note that a QUIC implementation cannot even tell if a CRYPTO_HS frame found in a 0-RTT packet contains a full EOED message, so we will be required to add a flag to a 0-RTT packet telling the peer that complete EOED has been delivered.

These requirements seem wired to me. Why not just send EOED using a Handshake 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/1377#pullrequestreview-122609536

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 07:39:28 -0700

The other reason to send EOED using a Handshake packet would be to minimize the changes related to the security from TLS. In TLS, EOED is protected by the handshake traffic key. Sending EOED using a 0-RTT packet will mean that we will be changing the traffic key of the message to a different key.

-- 
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/1377#discussion_r190273274

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 May 2018 09:27:13 -0700

Please forgive me for being a complete idiot. The issues pointed out here is based on the assumption that the TLS stack will activate the handshake key before receiving EOED sent using a 0-RTT packet.

They are all non-issues, if the TLS stack delays the activation of the handshake key until it receives EOED (and that is what the stacks are doing now).

-- 
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/1377#discussion_r190315163

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 May 2018 00:32:29 -0700

+The keys for the remaining encryption level are computed in the same
+fashion as the corresponding TLS keys (see {{TLS13}}; Section 7),
+except that the label for HKDF-Expand-Label uses the prefix "quic "
+rather than "tls 13". The purpose of this change is to provide key
+separation between TLS and QUIC, so that TLS stacks can avoid
+exposing TLS record protection keys.

I would like to see two clarifications here.

Am I correct in assuming that we would be using a modified version of HKDF-Expand-Label (that uses "quic " as the prefix) only when calculating the traffic keys? The other interpretation would be that we would be using the modified version for all cases (e.g. in Derive-Secret, when calculating the finished key). My preference goes to the former considering the fact that we are trying to change the traffic layer (i.e. TLS record) only.

The second issue is that the text seem to state that the non-modified version of HKDF-Expand-Label will be used for calculating the Initial Secret. I'd assume that it is a defect of the text.

-- 
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/1377#pullrequestreview-124279091

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 May 2018 02:07:01 -0700

gloinul commented on this pull request.

+encryption level are the same in QUIC as in TLS over TCP:
+
+- CRYPTO_HS frames MAY appear in packets of any encryption level.
+- CONNECTION_CLOSE and CRYPTO_CLOSE MAY appear in packets of any
+  encryption level other than 0-RTT.
+- PADDING and PING frames MAY appear in packets of any encryption level.
+- ACK frames MAY appear in packets of any encryption level, but
+  MUST only acknowledge packets which appeared in that encryption
+  level.
+- STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels.
+- All other frame types MUST only appear at the 1-RTT levels.
+
+Because packets may be reordered on the wire, QUIC uses the packet
+type to indicate which level a given packet was encrypted
+under [TODO: Table needed here?]. When multiple packets of

Please add a table for clarity. Frame types and Packet Types are after all two dimensions and clarity on how encryption level to packet type needs to be clear. And it isn't currently.

-If 0-RTT is not attempted, then the client does not send packets protected by
-the 0-RTT key (@0).  In that case, the only key transition on the client is from
-handshake packets (@H) to 1-RTT protection (@1), which happens after it sends
-its final set of TLS handshake messages.
+~~~
+{: #quic-tls-handshake title="QUIC Handshake"}

Is it possible to include packet types in the above diagram, not only the key's symbols? 

-- 
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/1377#pullrequestreview-124310962

---

From: ekr <[email-masked]>
Date: Wed, 30 May 2018 13:27:46 +0000 (UTC)

ekr commented on this pull request.

Glad that you raised this. I was assuming the former. I believe the latter would be safe but I would love to heard from @ad-l on this point.

The second is just a bug.

-- 
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/1377#discussion_r191766355

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Wed, 30 May 2018 08:33:51 -0700

ad-l commented on this pull request.

Indeed, replacing all HKDF expansion labels in the TLS key schedule is the more conservative approach, as it prevents some secrets from being portable between TLS and QUIC. Most notably, if only the record key expansions use the "quic " label prefix, session tickets and PSK binders may potentially be re-used across the two protocols. /This is not necessarily a bad thing/ - a modular security model for the TLS handshake can in fact accommodate this a as feature and tolerate sessions that use a mix of record protocols. 

I would say it is up to the IETF to decide whether it wants the two protocols to be immiscible or not. If nobody sees value in mixed-transport sessions, going for disjoint labels is a cheap way to reduce the attack surface of both protocols and ensure they can be analyzed independently. 

-- 
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/1377#discussion_r191815607

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 May 2018 16:56:47 -0700

@ekr @ad-l Thank you for the guidelines. The impact of sharing the labels are now clear to me.

To me now it seems that one way of making the decision in QUIC would be to follow the precedent that is soon going to be set by DTLS 1.3.

If DTLS allows session resumption using a ticket obtained through a TLS connection, I do not see why QUIC should disallow it. If DTLS uses the same traffic key as TLS does, I do not see why QUIC cannot use it as well.

Is my understanding correct that  DTLS 1.3 uses the same label for all the cases?

-- 
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/1377#discussion_r191956715

---

From: David Benjamin <[email-masked]>
Date: Wed, 30 May 2018 17:24:30 -0700

davidben commented on this pull request.

Changing the labels means a future QUIC + TLS 1.4 will lose the version distinguisher, no? So that means that it will impede reuse of the analysis in different direction. If just changing the record-layer labels, that's probably fine since those secrets are derived from earlier versioned secrets. But that is a new detail that must be accounted for in the analysis. If changing the whole thing, then it's no longer obvious that TLS 1.4 will work smoothly.

I'm also not eager to have to route in logic to switch labels around everywhere. (See how the `[sender]_write_key`, `[sender]_write_iv`, and KeyUpdate derivations were tweaked so as not to incorporate the side, because the base secrets already did so. That turned out to be a surprisingly large simplification to the implementation.)

Record-layer labels are less of a big deal, but I'm a little confused how even changing them helps the protocols be analyzed independently. We're already splitting TLS apart at the record layer bits, so the record layer portions of the analysis already must be reworked or accounted for in some way. It doesn't seem like changing the labels reduces the contact points.

I agree that aligning with DTLS 1.3 makes sense, including the labels. It seems to be the same scenario: we share the handshake, but tease apart the record layer. (Is DTLS 1.3 changing the labels at all? I don't see any indication of it doing so, but maybe I missed 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/1377#discussion_r191960366

---

From: ekr <[email-masked]>
Date: Wed, 30 May 2018 21:52:23 -0700

DTLS 1.3 uses the same labels. 

@davidben the rationale here was less about analysis than about being to build a TLS 1.3 stack that guaranteed that it would keep the *TLS* keys internally. And this was intended as a cheap way to do that. I'm not religious about it, but there was some enthusiasm for it on the design team, so I suggested 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/1377#discussion_r191988914

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 May 2018 22:12:50 -0700

> the rationale here was less about analysis than about being to build a TLS 1.3 stack that guaranteed that it would keep the _TLS_ keys internally. And this was intended as a cheap way to do that. I'm not religious about it, but there was some enthusiasm for it on the design team, so I suggested it.

@ekr I remember having that discussion. OTOH, I do not recall discussing about _which_ (or that all) keys should be kept internally. It could be the case that the hesitation that some had was against sharing _one_ key between two stacks; an issue orthogonal to how we define the labels.

I think that we should discuss the issue in the working group to see what the concern is (or if such a concern really exists).

-- 
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/1377#discussion_r191990843

---

From: David Benjamin <[email-masked]>
Date: Wed, 30 May 2018 22:28:17 -0700

@ekr Ah, that makes sense. I think we should try to avoid bifurcating all the labels but the "exported" record keys will need a dedicated path anyway, so it's hopefully not a huge deal either way.

Though having it lose the versioning is a little odd. Should it be a different input to hkdf-expand-label instead?

-- 
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/1377#discussion_r191992369