[noise] verifying received static remote key

[Trevor Perrin]

On Thu, Nov 2, 2017 at 11:06 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> I don't think the spec pseudocode needs to handle invalid patterns.
>
> Oh right, so no such patterns can exist. OK I got it now :)
>
>
>> I'm not super-eager to make the pseudocode more complicated,
>> particularly when this is just adding more emphasis ("authentication
>> is important!") for something the spec already explains.
>>
>> Also, there are ways of doing authentication that don't fit into a
>> blocking verifyRemoteStaticKey() function.  For example, maybe the
>> authentication check requires a network lookup ("is this key good, or
>> revoked?") so will happen in parallel with the rest of the handshake.
>
> In this case what about the following:
>
> 1. have a `remoteKeyValid` boolean in the handshake state
> 2. have split() make sure this boolean is set to true before returning correctly
> 3. have initialization() set the boolean to true when the rs is set
> 4. in any other cases, the implementers will have to find a way to set
> this to true


You mean initialization() sets it to false, I think?  And split()
checks that rs is either empty or the boolean is true?

You're still assuming that verification always completes before
split().  I could imagine other implementations (in particular if
verification is a separate thread doing online lookups).

Let's think about this more, and revisit once we're editing another
spec revision.  I like keeping the pseudocode simple and focused on
crypto logic, so I'm not super-excited about a "placeholder" boolean
that doesn't do anything except serve as a reminder.

Adding a bullet in "Application responsibilities" might be a
lighter-touch way of adding more emphasis to authentication.

Trevor