[noise] Extra key derivation - use cases, mechanisms

[Trevor Perrin]

Mulling this over, I increasingly like the idea of using "k" itself
for rekey/extra key derivation, instead of using HKDF to derive
separate key-deriving keys.  Couple reasons:

First, using the cipher key to rekey itself is efficient, and
efficiency makes per-message rekeying more feasible.  Per-message
rekeying is optimal, because it guarantees that keys can be deleted
after use.

Secondly, using "k" for extra derivation also means:

 (A) The forward-secrecy benefit of rekeying is extended to keys
derived from k.  For contrast: In TLS 1.3 the traffic keys are
re-keyed but the exporter keys are not, so a device compromise would
always compromise old exported values.  However if the (re-keyed)
traffic key and the exporter key are the same (k), then old exported
keys would get forward secrecy.

 (B) During the handshake, extra key derivation is automatically
defined as long as "k" is defined.  In TLS 1.3 key derivation has to
be explicitly defined at various stages, e.g. there's an
"early_exporter_secret" and an "exporter_secret", but there's no
"middle_exporter_secret" for use alongside the handshake traffic
secrets, and there's no resumption secrets for use earlier.  Maybe
that's OK in TLS, but Noise can support handshakes with more stages,
so it's nice to have an automatic definition for extra key derivation
at any handshake stage.

?

Trevor


On Thu, Jan 19, 2017 at 10:23 AM, Trevor Perrin <trevp at trevp.net> wrote:
> 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