[noise] Reworking PSK usage

[Alex]

On Tue, 2 May 2017 19:29:08 +0000
Trevor Perrin <trevp at trevp.net> wrote:

> Hi all,
> 
> Jason's put a lot of thought into PSKs in Noise and WireGuard and
> pointed out the current Noise design could use improvement:
> 
> Noise currently assumes the "preshared symmetric key" is known to both
> parties prior to the handshake, so you can mix it in before other
> secret keys.  But for patterns that transmit identities, it would make
> more sense for the PSK to be a pairwise value that only gets mixed in
> once the parties learn each other's identity, and can lookup the
> pairwise PSK from some database.
> 
> Concretely, something like WireGuard might want a pattern like:
> 
> <- s
> ...
> -> e, es, s, ss  
> <- e, ee, se, psk
> 
> Where the "psk" token means "mix in the PSK now".  You could put the
> token earlier, for example at the end of the first message, if you
> assume knowledge of the initiator's "s" is sufficient to identify the
> correct PSK.  But you might want it later, if something in the first
> message's payload is needed to lookup the PSK, or for DoS-resistance
> if you want to decrypt the first message's payload without consulting
> the PSK database.  So having a "psk" token gives flexibilty for those
> decisions.
> 

(A) Does the addition of this token allow the user to construct invalid
handshakes? For example, what if the psk token is specified twice in a
row? Is that valid?

> Some questions pop up:
> 
> (1) How do we name this?  It seems like we're moving towards a naming
> syntax of having modifiers within the pattern field, like "XXhfs" or
> "XXfallback+sig+hfs", so we should probably align with that, instead
> of the current special-case syntax of "NoisePSK_XX".  We'd probably
> like the name to indicate PSK placement.  I'll argue the most likely
> PSK placements are at the beginning of the handshake, or at the end of
> a message:
>  * At the beginning of a handshake, we should still probably put it
> after "e" since the spec currently assumes message patterns start with
> ""e"
>  * At the end of a message means it will come after any "s" tokens in
> that message, and keeps the patterns easy to read.  So we could name
> things like:
> 
> Noise_IKpsk0:
> <- s
> ...
> -> e, psk, es, s, ss  
> <- e, ee, se
> 
> Noise_IKpsk1:
> <- s
> ...
> -> e, es, s, ss, psk  
> <- e, ee, se
> 
> Noise_IKpsk2:
> <- s
> ...
> -> e, es, s, ss  
> <- e, ee, se, psk
> 
> This doesn't rule out other placements, it just means we might need to
> extend the naming scheme down the road.
> 

(B) If multiple psk tokens are technically valid, how would you fit
that in to the proposed naming scheme?

(C) Where does the "psk" designation belong? For example, which one of
these is correct?:

* Noise_NNhfs+psk0
* Noise_NNpsk0+hfs

(D) I feel that the pattern naming is getting a tad clunky when you
factor in transformations, the newly proposed psk token, etc. What do
think of a naming scheme in which you serialize the entire handshake,
hash it, and use that as the naming scheme? For example,

pattern name = HASH("s!e:es:s:ss:psk;e:ee:se") -- or something similar.

-- 
Alex