Stream0 dt output ready #1377

ekr · 2018-05-23T01:25:58Z

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

See: https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit for design rationale.

mikkelfj · 2018-05-23T02:03:45Z

draft-ietf-quic-recovery.md

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

mikkelfj · 2018-05-23T07:47:21Z

draft-ietf-quic-tls.md

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

mikkelfj · 2018-05-23T08:06:51Z

draft-ietf-quic-transport.md

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

Remove smart quotes

kazuho · 2018-05-23T14:24:53Z

draft-ietf-quic-tls.md

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

EDIT. My argument is based on the understanding is that EOED merely exists to mark the boundary between keys when TLS uses TCP as a transport. In case of TLS messages over QUIC, we have distinct packet types for 0-RTT and handshake packets, and there is no necessity to send it using a 0-RTT packet (aside from aesthetic reasons).

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.

EDIT. Sorry, under the TLS spec., EOED is protected by the early traffic secret. So we need to send it using a 0-RTT packet to minimize the impact of moving to a different packetization scheme. I think my comments about the wiredness still holds.

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

kazuho · 2018-05-30T07:32:23Z

draft-ietf-quic-tls.md

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

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.

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.

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

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

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.

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

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

gloinul · 2018-05-30T09:05:40Z

draft-ietf-quic-tls.md

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

gloinul · 2018-05-30T09:06:32Z

draft-ietf-quic-tls.md

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

I will add a new diagram.

ekr added 2 commits May 22, 2018 18:13

Output of Stream 0 Design Team.

b458f4e

See: https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit for design rationale.

Fix changelog

9ffd3f1

mikkelfj reviewed May 23, 2018

View reviewed changes

ekr and others added 3 commits May 22, 2018 19:11

Fix whitespace

1a30fc6

Offset and length fields in CRYPTO_HS are not optional

c0d3cbc

Remove smart quotes

66350c8

mikkelfj reviewed May 23, 2018

View reviewed changes

Merge pull request #30 from quicwg/stream0

c38e7ee

Remove smart quotes

kazuho reviewed May 23, 2018

View reviewed changes

tatsuhiro-t mentioned this pull request May 23, 2018

TLS1.3: Stateless retry and CCS openssl/openssl#5235

Closed

Ralith mentioned this pull request May 25, 2018

Implement support for QUIC rustls/rustls#161

Closed

kazuho reviewed May 30, 2018

View reviewed changes

gloinul reviewed May 30, 2018

View reviewed changes

MikeBishop mentioned this pull request Jun 8, 2018

Move stream type into frame type #1431

Closed

martinthomson closed this Jun 26, 2018

kazuho mentioned this pull request Nov 6, 2018

Where does the "quic " HKDF label apply? #1971

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stream0 dt output ready #1377

Stream0 dt output ready #1377

ekr commented May 23, 2018

mikkelfj May 23, 2018

mikkelfj May 23, 2018

mikkelfj May 23, 2018

kazuho May 23, 2018 •

edited

Loading

kazuho May 23, 2018 •

edited

Loading

kazuho May 23, 2018

kazuho May 30, 2018

ekr May 30, 2018

ad-l May 30, 2018

kazuho May 30, 2018

davidben May 31, 2018

ekr May 31, 2018

kazuho May 31, 2018

davidben May 31, 2018

gloinul May 30, 2018

ekr Jun 6, 2018

gloinul May 30, 2018

ekr Jun 6, 2018

Stream0 dt output ready #1377

Stream0 dt output ready #1377

Conversation

ekr commented May 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kazuho May 23, 2018 • edited Loading

Choose a reason for hiding this comment

kazuho May 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kazuho May 23, 2018 •

edited

Loading

kazuho May 23, 2018 •

edited

Loading