[noise] Extra key derivation - use cases, mechanisms
scratch.net at gmail.com
Thu Mar 2 12:54:04 PST 2017
Just saw a new rekeying draft
might be useful
From: Trevor Perrin [mailto:trevp at trevp.net]
Sent: Monday, February 27, 2017 1:16 AM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Extra key derivation - use cases, mechanisms
On Sun, Feb 26, 2017 at 10:29 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> I have some thoughts about renegotiation which is lazy, lock-free and app-level transparent.
> Until client receives "Renegotiation done" from server, it continues
> to decrypt server packets using K2
> At some 4th random point in time Server receives "Renegotiation done"
> from client, calculates K3/K4, throws away K1, switching to K3 for
> decryption messages from client
> Thus we achieve transparent renegotiation without app level knowing that it happened at all.
> Moreover, we can use advantage of knowing previous static keys / trust
> and use patterns like KK or even NN
Sure, this is similar to TLS <= 1.2 which allowed renegotiation by sending handshake messages, which are a different "record type" from application messages so can be multiplexed with them, and then at some point you switch keys.
TLS 1.3 removed that, I think because the main use was adding post-handshake client auth, but that can also be done with channel bindings. And renegotiation gave rise to security problems because the inner session wasn't bound to the outer session in TLS. (In Noise, you'd want to include the outer session's "h" in the inner session's "prologue").
Also, you can just do what WireGuard does and periodically create a new session, which is simpler.
Renegotiation could be put in a future NoiseSocketv2 or something if we think it's useful, but I would leave it out of the initial NoiseSocket, whose goal is to be simple.
More information about the Noise