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
Combined from comments I originally made on Nov 9 to Nov 28, 2022.
We already have replay protection within TCP streams due to use of hydrogen's message numbers. It will protect against pieces within TCP sessions from being replayed. It will not protect from replay of TCP sessions (entire or partial) from their beginnings.
We could also implement protection against replay of TCP sessions, in three ways:
If we continue to use or allow data payloads without a full handshake (non-interactive Noise pattern or first step in an interactive pattern), we could check timestamps inside first messages of TCP sessions, and impose restrictions on whether/when/how time can go back.
We could implement an interactive Noise pattern (which we'd also want for forward secrecy) and only be sending data payloads after full handshake.
If we implement client authentication via challenge/response and with at least the response coming as a Noise payload, this can also defeat replay even while keeping the non-interactive Noise pattern.
The text was updated successfully, but these errors were encountered:
Combined from comments I originally made on Nov 9 to Nov 28, 2022.
We already have replay protection within TCP streams due to use of hydrogen's message numbers. It will protect against pieces within TCP sessions from being replayed. It will not protect from replay of TCP sessions (entire or partial) from their beginnings.
We could also implement protection against replay of TCP sessions, in three ways:
The text was updated successfully, but these errors were encountered: