[noise] Resumption PSKs

[Christopher Wood]

On Tue, Jun 5, 2018 at 2:02 AM Trevor Perrin <trevp at trevp.net> wrote:
>
> On Mon, Jun 4, 2018 at 3:00 PM, Christopher Wood
> <christopherwood07 at gmail.com> wrote:
> >
> > Would it not be cleaner to move this export functionality to a
> > different API? For example, one could specify an explicit Export() API
> > that functions precisely as you describe above, with the exception
> > that CipherState objects are not returned.
>
> Hi Chris,
>
> The issue is that the transport keys and these new "key chains" have
> to be created at the same time, so that the value used to derive them
> (the chaining key ck) can be deleted afterwards.
>
> Put another way: a goal is that additional key outputs are independent
> from each other and from the parent session's keys, at any point in
> time ("independent" in the sense that none of these keys can derive
> the others).
>
> Thus we're avoiding designs where the parent session would hold a
> single long-lived key and repeatedly produce outputs from it.

It seems as though one can accomplish this by generating the transport
and key chains at the
same time (from ck) and then simply discard both ck and the transport
keys. I'm not advocating
for an API that allows clients to pump out keying material
indefinitely from the same root. I was
just hoping to avoid overloading an already well-defined and clearly
specified API.

>
> As far as terminology, we should do something better than "key chains"
> (confusing wrt to the "chaining key", which is a different thing).
> You mention "Export", which is a similar concept in TLS (except TLS
> uses separate mechanisms for "exported" keys and resumption keys, and
> we'd just use a single mechanism).
>
> But I don't think that's great terminology either, since "export" is
> often used by things like crypto APIs / HSMs that take an internal key
> and wrap it so it can be imported into other devices.

Fair point. I was primarily thinking of TLS with the suggestion. :-)

Best,
Chris