On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner <[email protected]> wrote: > > 2) Fall back to an interactive handshake using cookies. Define a protocol > version two, mandate that in V2 the cookie must be mixed into the handshake > hash. Assign a cookie in case of timestamp failure.
That could be deployed in a backwards-compatible way, I think? If the client's V1 handshake is rejected due to an old timestamp, the client is given the cookie which enables it to do the V2 handshake? > Jason pointed out, that it would be preferable to use a Noise-XK handshake > which is a standard fully-interactive handshake but 1.5-RTT. I was assuming > 1-RTT-ness was a necessity. > Of course, coming up with a new handshake is…generally foolish and even > though both my proposal technially fit into the noise-IK pattern, noise-XK > certainly is more trustworthy. I thought the goal of IK here was: server only stores state if client is authenticated. And the goal of timestamp was: replayed messages can't invalidate an existing session state. If those are still the requirements I'm not sure that XK meets them. XK has better identity hiding (only reveals the client's identity after forward-secrecy is negotiated), but that trades off against the requirement that unauthenticated clients can't cause servers to store state. (Unless you put the state in a cookie, I suppose - which you also suggested...) Trevor
