[noise] Does the NK handshake pattern require a separate server pubkey check?

[Trevor Perrin]

On Mon, Apr 13, 2020 at 4:40 PM David Fifield <david at bamsoftware.com> wrote:
>
> I'm designing a proxy protocol using Noise. The client is
> unauthenticated; the server has a static public key which the client
> knows in advance, out of band. The NK handshake pattern seems like the
> best fit for this model.
>         NK:
>           <- s
>           ...
>           -> e, es
>           <- e, ee
>
> I've also read this part of the spec:
>         https://noiseprotocol.org/noise.html#security-considerations
>         Authentication: A Noise protocol with static public keys
>         verifies that the corresponding private keys are possessed by
>         the participant(s), but it's up to the application to determine
>         whether the remote party's static public key is acceptable.
>         Methods for doing so include certificates which sign the public
>         key (and which may be passed in handshake payloads),
>         preconfigured lists of public keys, or "pinning" /
>         "key-continuity" approaches where parties remember public keys
>         they encounter and check whether the same party presents the
>         same public key in the future.
>
> 1. Am I correct in thinking that no separate post-handshake check of the
>    server's public key is needed, when using the NK pattern?

Hi David,

Yes that's correct.

> 2. Am I correct that if the pattern were instead NX, that the client
>    *would* have to check, after the handshake, that the s received from
>    the server is the expected public key?

Well, if the client already received the server's public key
out-of-band it wouldn't have to check it, but in that situation
there's no reason to be using NX.  I.e. NX could be used just like NK
and has the same authentication properties, it just additionally
transmits the public key in case the client doesn't already have it.

Trevor