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

[Trevor Perrin]

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