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

[Trevor Perrin]

On Mon, Mar 20, 2017 at 12:51 AM, Trevor Perrin <trevp at trevp.net> wrote:
> On Sun, Mar 19, 2017 at 9:44 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>>
>> 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).
[...]
> 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

Thinking on this more, I think the best options for NoiseSocket are either:

(A) No 0-RTT, keep it simple

(B) Semi-ephemeral 0-RTT, where the server's first response always
contains its current "resumption public key" in the payload, which is
either a semi-ephemeral public key, or just a copy of the server's
static public key.  The client can use the resumption public key for
an IK+semiresume resumption.

This is better than plain IK, because it allows the semi-ephemeral to
be rotated more quickly, for forward secrecy.  It's not much more
complicated than IK (the server can use its static public key in place
of the semi-ephemeral, to avoid extra key management).

Compared to resumption PSKs this has:
  - Better security (stronger resistance to key-compromise
impersonation, due to public-key crypto)
  - More flexibility, since it allows 0-RTT initial connections if you
can look up the resumption public key, not just resumptions
  - Simpler, since less juggling of session tickets (and no worry that
re-use of session tickets will be "linkable" to an observer).

Trevor