Re: [quicwg/base-drafts] Stream0 dt output for merge (#1450)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

Busy implementing this. It would be much easier to work draft-13 than parsing the PR...

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

I am busy implementing this, and I have a small issue with the "MAY appear in packets of any encryption level." How do I verify that the packets are sent as intended? For example, what if I receive a CRYPTO_HS frame with offset 500 in an  handshake-protected, and another CRYPTO_HS frame with an overlapping offset in an application-data protected packet?

I think there is a subtle interaction there between offset sequencing in CRYPTO_HS and per-stream packet sequence numbers.

> +
+- 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, as shown in {{packet-types-levels}}. When multiple packets of
+different encryption levels need to be sent, endpoints SHOULD use
+coalesced packets to send them in the same UDP datagram.

This changes coalesced packets from an optional performance-oriented feature to an almost mandatory security related feature. We should make clear that sending coalesced packets is optional.  

-- 
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/1450#pullrequestreview-130214629