Avoid race condition with peer in server path secret map read

[Mark-Simulacrum]

Security issue notifications

If you discover a potential security issue in s2n-quic we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

Currently a sequence like:

• Client starts + finishes handshake for secret A
• Client starts handshake for secret B
• Client sends a datagram packet, encrypted with A
• Server receives on_peer_stateless_reset_tokens, inserts B into the path secret map
• Server looks up IP, gets B, encrypts + replies
• Client looks up path secret B and fails since handshake for B is not yet complete

Solution:

We need to delay the insertion into the peer set (i.e. by-ip index) on the server until the handshake is fully complete (and so the client is able to decrypt that IP). That probably involves changes to the dc::Endpoint trait to communicate that new state.

Requirements / Acceptance Criteria:

n/a

Out of scope:

• Removing an entry if the client fails to confirm the handshake.
• Race conditions that still cause the same sequence to occur, with the client confirming the handshake after completing a separate handshake. This is probably most likely with a delayed packet and a restarting client.
  • If possible we should cover this too, but it's probably hard or impossible.

[dougch]

Thanks for the issue, we'll have a look.