another thread on montonic counter alternatives

[Trevor Perrin]

On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner <karo at cupdev.net> 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