[noise] verifying received static remote key

[Trevor Perrin]

On Wed, Nov 1, 2017 at 4:54 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
>> For "s": Sets temp to the next DHLEN + 16 bytes of the message if HasKey() == True, or to the next DHLEN bytes otherwise. Sets rs (which must be empty) to DecryptAndHash(temp).
>
> I think it should include two additional steps:
>
> 1) IF the remote static key is known because it was processed during a
> pre-message pattern, it needs to be checked against the received one.
> If they are different, the handshake needs to be aborted.

That's an illegal pattern (section 7.1, pattern validity rule #2 - a
key can only be sent once, including pre-messages).


> 2) ELSE, a verifyRemoteStaticKey() function (or something like that)
> needs to be called on the received static remote key. If it returns
> false, the handshake needs to be aborted.
>
> Without that, the static keys are accepted right away in N or X
> patterns. I agree that verifying a transmitted (X) key is out of scope
> for the document, nonetheless I think it should still declare either a
>  verifyRemoteStaticKey in the handshakeState, or as an argument to
> ReadMessage. And the spec should also mention that this is a sensitive
> function to implement and that it is the role of the designer to come
> up with something to verify the key.


We added a Security consideration in revision 33 to discuss this
("Authentication").

I'm not convinced about putting this in the pseudocode.  For one
thing, you might perform the check at different points.  For example,
if the handshake payload contains certificates, the check would not
occur on processing the static but would be deferred until processing
the payload.

It's not so easy to describe these options in pseudocode without
cluttering it, thus I'm hoping the Security consideration suffices.

Trevor