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

[Alexey Ermishkin]

We will also need to support different mechanisms like 0-RTT/IK/XK whatsoever whose count I guess will be multiplied by the amount of ciphercuites which looks like a too much work for a single byte.
Another problem is that we'll have to say that "0 is Noise_XX_25519_ChaChaPoly_SHA256, 1 is foo, 2 is IK + Noise_XX_448_ChaChaPoly_SHA256 ". and keep the list somewhere.

I personally think that relying on strings in security is a very, very bad idea, but maybe we should really use strings as it was intended by the spec? Or at least hash from that string as a ciphersuite ID. Same could be applied to patterns. It's 32/64 extra bytes per handshake message  depending on how we'll treat those 2 strings, but it's something that could be described in one paragraph and does not need to be hardcoded


-----Original Message-----
From: Noise [mailto:noise-bounces at moderncrypto.org] On Behalf Of Trevor Perrin
Sent: Tuesday, January 17, 2017 1:40 PM
To: Rhys Weatherley <rhys.weatherley at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] A simple and safe TLS/TCP-like protocol

On Mon, Jan 16, 2017 at 11:05 PM, Rhys Weatherley <rhys.weatherley at gmail.com> wrote:
> 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.

The limit would be 255, and no more than 64K bytes total in the first message.


> 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.

Maybe, but that assumes you can anticipate the fallback.  A quantum computer, break in ECC, or protocol flaw, would leap over your fallback...


> 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).

Once we have to support a few versions it's probably easier to support
255 than anything else.

Certainly you shouldn't maintain support for broken protocols, but I'm not sure that restricting the version mechanism helps with that, and it adds an artificial annoyance if someone does want more versions.

Trevor
_______________________________________________
Noise mailing list
Noise at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/noise