Re: [quicwg/base-drafts] Separate key/secret availability from usage (#1654)

[Christian Huitema <[e-mail]>]

huitema approved this pull request.

I think this text is better than the previous one. 

I suggest adding a paragraph about the need for reordering before submission to TLS. It is somewhat redundant, and I would understand that editors decide to do without. But I think it is important to hammer this point, as it is an important part of the design.

> -CRYPTO frame in Handshake encryption) may send STREAM data (in 1-RTT
-encryption). However, if the Finished is lost, the client would have to
-retransmit the Finished, in which case it would use Handshake encryption.
-
+Although TLS only uses one encryption level at a time, QUIC may use more than
+one level. For instance, after sending its Finished message (using a CRYPTO
+frame at the Handshake encryption level) an endpoint can send STREAM data (in
+1-RTT encryption). If the Finished message is lost, the endpoint uses the
+Handshake encryption level to retransmit the lost message.
+
+In particular, server implementations need to be able to read packets at the
+Handshake encryption level before the final TLS handshake message at the 0-RTT
+encryption level (EndOfEarlyData) is available.  Though the content of CRYPTO
+frames at the Handshake encryption level cannot be forwarded to TLS before
+EndOfEarlyData is processed, the client could send ACK frames that the server
+needs to process in order to detect lost Handshake packets.
 

Looks good. You may or may not want to hammer the point about ordering. Something like this:

Proper operation of TLS requires that handshake octets be delivered to the TLS receiver in the order in which they were produced by the sender but QUIC can only guarantee ordering within an encryption level. Due to possible reordering and losses it is possible that encryption level 1 messages sent in 0-RTT packets arrive after level 2 messages sent in Handshake packets. QUIC receivers need to make sure that handshake messages are only submitted to TLS when TLS is ready to accept messages at that encryption level.

-- 
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/1654#pullrequestreview-145746786