[noise] Extra key derivation - use cases, mechanisms

[Trevor Perrin]

On Thu, Jan 19, 2017 at 7:01 AM,  <alex at centromere.net> wrote:
> On 2017-01-19 05:49, Trevor Perrin wrote:
>>
>> We've had a few discussions about deriving extra keys for various
>> uses.  I'll try to collect the use cases and some options:
>>
>> Use cases for extra keys
>> -------------------------
>>
>> (1) REKEY:  During the transport phase, the application might want to
>> replace an old k with new k such that compromise of new k doesn't
>> compromise old k.
>>
>
> Could this legitimately be called "forward secrecy"?

Possibly. I'd use that term informally, though "forward secrecy" is
defined differently by different people, so to be precise it's better
to spell out what you mean.


> If the adversary compromises the first/oldest k, you're completely SOL,
> right?

Yes.


>> (2) PSK for renegotiation/resumption:  A key derived from an old
>> session could be used as PSK in a new handshake either contained
>> within the original session (renegotiation) or some time later
>> (resumption).
>>
>
> What exactly is the difference between renegotiation and resumption?
>
> Does the former require one or more DH operations while the latter
> requires zero?


We haven't really defined "renegotiaton" and "resumption", and they
would take a lot more effort to specify, but I was thinking of them as
analogous to TLS - renegotiation is a new handshake inside an old
session, resumption is a new handshake after an old session.

It might be true that a resumption handshake avoids DH entirely, and
just uses the PSK, but that's not a concept we really have in Noise,
so that's something we'd have to grapple with later.

For this discussion, the important point is that these are reasonable
things to want to derive an extra key (PSK) for.

Trevor