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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



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

@huitema 
> In fact, just ordering them is not sufficient, because the QUIC implementation does not actually know how long a particular crypto stream is. There is no end mark. So how does it logically deduce that level N is now done, and that it is OK to proceed with N+1?

IIUC our assumption is that the TLS stack will somehow notify the QUIC stack what the current read epoch is, and that the QUIC stack will only supply the contents of CRYPTO frames received in that epoch.

In my view, the following sentence in the PR implies that.

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

Or is it the case that you are uncomfortable with the text dealing with how to handle TLS messages?

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