[noise] A simple and safe TLS/TCP-like protocol

[Rhys Weatherley]

On Tue, Jan 17, 2017 at 6:09 AM, Trevor Perrin <trevp at trevp.net> wrote:

>  * Suppose the client wants to offer three new ciphers (version 1-3)
> but reuse the version 0 DH.  The client can send version indicators
> for 1-3, each followed by a zero-length message, reusing the version 0
> message's ephemeral public value.
>

I would put a limit on how many versions can be offered.

I monitor the cryptography list and there's been lots of discussion on
version/ciphersuite negotiation over the years.  One point of view (Ian G's
I think) is one I agree with.  I'll try to summarise (apologies to the
original authors if I get this wrong).

The protocol only supports two "versions": the current recommended one and
a fallback.  For example, Noise_XX_25519_ChaChaPoly_SHA256 and
Noise_XX_448_AESGCM_BLAKE2b.  The fallback is selected to have ridiculous
security compared to the recommended.

The purpose of this is to limit rollback attacks and to make upgrading to
new ciphersuites possible.  In the first protocol, implementations only
support versions 0 and 1 and prefer to use 0.  But they can use 1 if the
other side refuses 0.

This makes it possible to upgrade ciphersuites over time.  If version 0
falls to an attack, version 2 is defined and then implementations replace
their 0/1 implementation with a 1/2 implementation.  This allows for
emergency switch off of a broken ciphersuite and a clear migration path.

This could be extended to three or four overlapping "versions", but my main
point is that the version window needs to be small to avoid situations
where a rogue man-in-the-middle can force everyone back to
Noise_XX_Broken2017 years from now (a la RC4 in SSL/TTLS).

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170117/77cf5b2e/attachment.html>