]> git.ipfire.org Git - thirdparty/openssl.git/commitdiff
quic conformance: add comment about section 10.2.3 conformance
authorPauli <pauli@openssl.org>
Wed, 19 Jul 2023 04:47:13 +0000 (14:47 +1000)
committerPauli <pauli@openssl.org>
Fri, 4 Aug 2023 01:55:45 +0000 (11:55 +1000)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21429)

ssl/quic/quic_txp.c

index 6c5465b42da190ea7e9db5964f13c952ad8a2c03..461dfaf238db5965755f8ab60922f9b8b28b8d18 100644 (file)
@@ -1237,14 +1237,14 @@ static int txp_should_try_staging(OSSL_QUIC_TX_PACKETISER *txp,
      * peer does not have the keys for the EL yet, which suggests in general it
      * is preferable to use the lowest EL which is still provisioned.
      *
-     * However (RFC 9000 s. 12.5) we are also required to not send application
-     * CONNECTION_CLOSE frames in non-1-RTT ELs, so as to not potentially leak
-     * application data on a connection which has yet to be authenticated. Thus
-     * when we have an application CONNECTION_CLOSE frame queued and need to
-     * send it on a non-1-RTT EL, we have to convert it into a transport
-     * CONNECTION_CLOSE frame which contains no application data. Since this
-     * loses information, it suggests we should use the 1-RTT EL to avoid this
-     * if possible, even if a lower EL is also available.
+     * However (RFC 9000 s. 10.2.3 & 12.5) we are also required to not send
+     * application CONNECTION_CLOSE frames in non-1-RTT ELs, so as to not
+     * potentially leak application data on a connection which has yet to be
+     * authenticated. Thus when we have an application CONNECTION_CLOSE frame
+     * queued and need to send it on a non-1-RTT EL, we have to convert it
+     * into a transport CONNECTION_CLOSE frame which contains no application
+     * data. Since this loses information, it suggests we should use the 1-RTT
+     * EL to avoid this if possible, even if a lower EL is also available.
      *
      * At the same time, just because we have the 1-RTT EL provisioned locally
      * does not necessarily mean the peer does, for example if a handshake