[noise] Resumption (was Re: Channel-bound keys)
trevp at trevp.net
Mon Mar 20 00:51:22 PDT 2017
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.
More information about the Noise