[noise] Resumption (was Re: Channel-bound keys)

[Trevor Perrin]

On Sun, Mar 19, 2017 at 9:44 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> Looks good, but took some extra time to understand, especially the semi-static vs semi-ephemeral keys.
>
> Do you think this should go into v1 or can wait till v2?


I was thinking about this for the Noise framework (main spec).  As a
framework, Noise should be capable of any 0-RTT method (static public
keys, semi-ephemeral public keys, or resumption PSKs).

What to do in NoiseSocket is another question.  I guess it depends on
what NoiseSocket is for.  We don't have a clear set of use cases for
it, which would help answer that.


But anyways, one option is to make NoiseSocket simple and safe and not
provide a 0-RTT mode, since any data sent in the first round-trip will
have complicated and weaker security properties than later data.

If you want to provide a 0-RTT mode, the simplest is probably just
using the static public key ("Pipes", Noise_IK).

Using a semi-ephemeral is more complicated, since:
 (a) the server is managing another key pair
 (b) the semi-ephemeral public key is sent to the client somehow
 (c) the client is storing this *plus* the server's public key.

But it has the nice security property that the server can rotate
semi-ephemeral keys more quickly than its static key, for better
forward secrecy.  And the server could present its static public key
as the semi-ephemeral public key to eliminate (a).

Resumption PSKs are mainly useful to reduce computation of the
resumption, they have weaker security than the public-key methods.

So in some sense the semi-ephemeral method has the "best" security
properties, but is the most complicated.

Probably doesn't answer your question!  I'd be fine with a simple
NoiseSocket for "v1", with no 0-RTT, so we can just get something out
quickly, and make it more elaborate if needed.


Trevor