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

[Alexey Ermishkin]

I haven't compared my implementation to TLS 1.3, but with keepalive disabled my noise implementation is about 10 times faster than TLS 1.2 (also keepalive disabled) and that's with XX, not IK. Seems like an answer to "can we live without 0-RTT for now"

As for semiresume, it looks like something that needs touching Noise libs. This is doable but for example Flynn haven't answered anything to my pull request which implements XXFallback yet,
https://github.com/flynn/noise/pull/9
so I'll have to use my own go Noise library for Noise socket and that's why I haven’t added Pipes to Noise Socket PoC yet. Maybe later I'll fork and continue development 

Also, I don't know about other use cases but ours involves using certificate-like entities(we call them cards) which can sign. And I thought of signing static noise key instead of ugly extracting it from cards and comparing. This looks like semi-static keys to me because I can generate "s" and "e" as often as I can and sign them  with server card.



-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Wednesday, March 22, 2017 12:21 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: Resumption (was Re: Channel-bound keys)

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