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

[Loup Vaillant-David]

Hi,

You sound correct on both counts.

Noise guarantees that the other party is using the static key you
specified (NK) or were transmitted (NX). The NK pattern will thus only
work with the client chosen server's key. In a sense, the client
validated the server's key before the protocol even started.  Then NX
pattern however requires this validation to be done after the fact,
because the client knows the server key only later.

A MITM, cannot possibly know the client's private ephemeral key, and
they supposedly don't know the server's private static key. Noise
guarantees they won't be able to intercept the communication without
causing the protocol to fail.  The best they can do is transport the
encrypted data, and observe sizes, timings etc.

Loup.



On Mon, 2020-04-13 at 17:40 -0600, David Fifield 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? I am
>    thinking that after the first message, a MITM attacker will not
> have
>    derived the same k as the client, and the client will reject the
>    server's handshake message for failing to authenticate.
> 
> 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?
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise