[noise] Extra key derivation - use cases, mechanisms

[Trevor Perrin]

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.

Trevor