Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)

[Nick Harper <[e-mail]>]

nharper commented on this pull request.



> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, and endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data.
+
+Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard all subsequent CRYPTO frames, or it MAY close the
+connection with an INTERNAL_ERROR code. In the case where an endpoint chooses to

The CRYPTO_ERRORs are TLS alerts (which are one byte) converted into QUIC error codes, so we can't pick one of those. I've created a new one CRYPTO_BUFFER_EXCEEDED.

> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.

I moved this to the end of section 7 in a new subsection.

> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, and endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data.
+
+Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard all subsequent CRYPTO frames, or it MAY close the
+connection with an INTERNAL_ERROR code. In the case where an endpoint chooses to

Done.

> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, and endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data.
+
+Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard all subsequent CRYPTO frames, or it MAY close the
+connection with an INTERNAL_ERROR code. In the case where an endpoint chooses to
+discard all subsequent CRYPTO frames, the packets containing these CRYPTO frames
+are still ACKed. An endpoint in this condition MAY tear down state for its

Done.

> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, and endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data.
+
+Once the handshake completes, if an endpoint is unable to buffer all data in a
+CRYPTO frame, it MAY discard all subsequent CRYPTO frames, or it MAY close the
+connection with an INTERNAL_ERROR code. In the case where an endpoint chooses to
+discard all subsequent CRYPTO frames, the packets containing these CRYPTO frames
+are still ACKed. An endpoint in this condition MAY tear down state for its
+cryptographic handshake, keeping only the material needed for the current
+encryption keys and any future key updates.

Dropped.

> @@ -1232,6 +1232,19 @@ handshake data start from zero in each packet number space.
 Endpoints MUST explicitly negotiate an application protocol.  This avoids
 situations where there is a disagreement about the protocol that is in use.
 
+Implementations need to maintain a buffer of CRYPTO data received out of order.
+Because there is no flow control of CRYPTO frames, and endpoint could
+potentially force its peer to buffer an unbounded amount of data.
+Implementations MUST support buffering at least 4096 bytes of data.

Yes, it applies during the handshake.

I've updated the text to discuss buffer sizing and separate out pre- vs post-handshake completion behavior.

-- 
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/2524#discussion_r266606030