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

[David Fifield]

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?