[quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)

[Antoine Delignat-Lavaud <[e-mail]>]

In TLS 1.3, 1-RTT secrets can be derived once the server finished is computed, when the handshake is half-complete. This allows the server to send application data without waiting for the client finished flight (a feature sometimes called 0.5-RTT in the TLS WG). This is safe because checking the peer's finished message is only required for receiving, and the finished must be received before any application traffic when using the TLS record layer.

In QUIC, the server may receive 1-RTT packets before the client finished. This can happen because of packet loss, or an active adversary deliberately dropping handshake packets from the client, or because the client is malicious and does not send its finished flight at all. As far as I understand, the current QUIC spec allows the server to process the 1-RTT packets and hand them to the application without waiting for the client finished. Doing this falls outside the scope of what is currently proved secure about the TLS handshake, and it leads to multiple problems:
- Deadlock when the network drops the client finished flight: see #2863
- Potential to bypass client authentication requirements: if a server is configured with required client certificate authentication during the handshake (e.g. for access control to a service), a client may send the request before the client finished flight. If QUIC passes the request to the application, it may incorrectly believe that the client has been authenticated.
- Potential for downgrade attacks: the client finished is used to explicitly authenticate the negotiation of algorithms in the handshake. Due to its defensive design, TLS 1.3 also implicitly authenticates the transcript in the transport secret derivation. However, the implicit authentication only holds for strong AEAD algorithms, whereas the explicit authentication relies on strong hash algorithms (and/or signature, depending on the mode). 

A reliable way to prevent all of these issues is to mandate that every 1-RTT packet sent by the client before the client finished frame is acknowledged by the server must include in the same datagram a copy of the finished packet (the same handshake packet may be sent in multiple datagrams). The overhead is limited because finished messages are short, so even with the overhead of the long packet headers and AEAD tag, less than 100 bytes are used in the datagram (leaving the rest for the 1-RTT short packet). If this is done, it is possible to enforce that a server must have checked the client finished before processing 1-RTT packets from the client.

Adding a new transport-level signal for handshake confirmation (as proposed in #3145) is a bad idea - in TLS, receiving the peer's finished message IS the the explicit handshake confirmation signal (which is why CCS is removed in 1.3). Instead, QUIC should simply ensure that the signal has been received. It's only an issue on the server side, because clients cannot decrypt 1-RTT packets without processing the server finished.

-- 
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/issues/3159