[noise] Does the NK handshake pattern require a separate server pubkey check?
david at bamsoftware.com
Mon Apr 13 16:40:48 PDT 2020
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.
-> e, es
<- e, ee
I've also read this part of the spec:
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?
More information about the Noise