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

[Kazuho Oku <[e-mail]>]

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.

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

My assumption is that such check will be provided as an API or a guideline by the TLS stack, and that therefore it is unnecessary to clarify in the specification on how that should be done.

For example, the `ptls_handle_messages` function of [picotls](https://github.com/h2o/picotls/pull/141) accepts the epoch as the argument, and returns an error if a TLS messages was being received in an incorrect epoch.

-- 
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#discussion_r196999359