jmg at funkthat.com
Sun Sep 2 19:46:53 EDT 2018
Peter Gutmann wrote this message on Sat, Sep 01, 2018 at 13:58 +0000:
> Viktor Dukhovni <cryptography at dukhovni.org> writes:
> >The right way to do single-suite protocols, is to tie all the choices to a
> >single protocol version. For shiny new parameters, bump the protocol
> >version. Client proposes its list of protocol versions, and server chooses
> >the highest supported.
> Even then, you have to be very, very careful with that. The TLS folks have
> been struggling for years with anti-rollback mechanisms, it's really hard to
> do them in a manner that isn't exploitable in some combination of
That's because they've been trying to keep backwards compatibility.
If you have a protocol designed from the start, it's not at all hard.
You simply integrate all protocol messages into your key generation,
that way if any messages are modified in transit, the two ends don't
derive the same key, and communications cannot happen. Looks like
Noise does it slightly differently, see link below.
The issues w/ TLS is that previous versions did not integrate
all protocol messages into the key agreement, and that the client would
have to "self downgrade" to allow broken servers to negotiate a
> It'd be interesting to see a proper research paper on how to do anti-rollback
> right, with full analysis and proofs to accompany it. So far the mechanisms
> have been mostly ad hoc, "this should probably do it unless someone
> demonstrates otherwise".
I don't know if there's a paper on the above, but Noise talked about
this and it's prologue data:
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the cryptography