You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We change TX state immediately before sending a client cert (if we're sending one), or otherwise immediate before constructing the client finished. This as-late-as-possible approach is to allow for early-data (which is of course not a problem for QUIC). With normal TLS we can continue writing early-data all the way up until the point that we start writing more handshake messages.
This won't work for QUIC — the TX secret for the Handshake EL needs to be raised at the same time as the RX secret for the Handshake EL is currently. This is immediately after the ServerHello is received by a client and before any other TLS message such as EncryptedExtensions, etc.
If a Handshake packet is lost, it cannot be retransmitted until the peer is able to send an ACK packet on the same EL. So if we have an RX secret for the Handshake EL but not a TX secret, any lost packets will basically deadlock the connection process during this time.
It's essential we provision both TX+RX secrets for the Handshake EL immediately after getting a ServerHello. We currently do this for the RX side only.
The text was updated successfully, but these errors were encountered:
From @mattcaswell:
This won't work for QUIC — the TX secret for the Handshake EL needs to be raised at the same time as the RX secret for the Handshake EL is currently. This is immediately after the ServerHello is received by a client and before any other TLS message such as EncryptedExtensions, etc.
If a Handshake packet is lost, it cannot be retransmitted until the peer is able to send an ACK packet on the same EL. So if we have an RX secret for the Handshake EL but not a TX secret, any lost packets will basically deadlock the connection process during this time.
It's essential we provision both TX+RX secrets for the Handshake EL immediately after getting a ServerHello. We currently do this for the RX side only.
The text was updated successfully, but these errors were encountered: