[noise] Resumption (was Re: Channel-bound keys)
scratch.net at gmail.com
Sun Mar 19 09:44:34 PDT 2017
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?
From: Trevor Perrin [mailto:trevp at trevp.net]
Sent: Friday, March 17, 2017 1:39 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Resumption (was Re: Channel-bound keys)
On Thu, Mar 16, 2017 at 3:43 AM, Trevor Perrin <trevp at trevp.net> wrote:
> We might consider aligning public-key (IK, XK, NK) and PSK resumption,
> so it was easier for protocols to support both.
> For example, the "channel-bound keys" thing doesn't work for
> semi-static public keys.
Thinking more about making different resumption methods similar.
Another idea, instead of channel-bound keys:
In addition to IK based on the server's static public key, we have two forms of resumption based on server-provided values:
(A) Resumption PSK and session ticket, or
(B) Short-lived ("semi-ephemeral") public key
To prevent the server relaying someone else's PSK or semi-ephemeral public key, we require a client to bind the server's identity in the first resumption message. Given that, PSK handling is simple: the server just sends the client the PSK.
To bind the server's identity, we could define a pattern transformation that adds the server's static as a pre-message, if it's not one already. E.g.
<- e, ee
Since we're using the server's static within the pattern, we can't treat the short-lived key as a "semi-static", so instead we have to consider it a "semi-ephemeral", since ephemeral keys are allowed to be replaced within the pattern. But a pattern-transformation for semi-ephemeral keys could convert the server's "s" to "e":
<- s, e
-> e, ee, s, se
<- e, ee, se
Is this making sense?
More information about the Noise