[PATCH] site: Replace remote's caps after verifying MSG3

[Ian Jackson]

>     site: Replace remote's caps after verifying MSG3
> 
>     Previously we'd just `or' the new capability bits into
>     `st->remote_capabilities' prior to verification, with the rather
>     unfortunate result that an adversary could convince us that the remote
>     site has features which it doesn't, in fact, implement.  At present, the
>     worst effect here is preventing key-exchange from completion, but it's
>     imaginable that future capability bits have worse effects.
> 
>     Instead, (a) simply replace our idea of the remote site's capabilities
>     rather than accumulating a union of all mentioned capabilities, and (b)
>     do this /after/ verifying the signature on the message.  (This is safe
>     because there's no mention of `st->remote_capabilities' in the
>     intervening code in `process_msg3', or in the common message-
>     verification code in `process_msg3_msg4'.)
> 
>     Signed-off-by: Mark Wooding <mdw at distorted.org.uk>

This code change seems to be good as far as it goes.

But: I observe that there doesn't seem to be any corresponding code on
the MSG4 path.  Ie the initiator just unconditionally trusts what was
in MSG2.

The early capability mechanism is not needed for MSG2.  It's only for
compatibility with ancient sites' MSG1 handling.  So I think the MSG4
path needs to check that the capabilities haven't changed ?

And, your message prompts me to think about the error handling.
Right now if the attacker modifies MSG1 so as to trip the "msg3
impermissibly adds early capability" check, the key exchange is
doomed.  Does this matter ?  The attacker can doom the key exchange
some other way.  I guess at least like this we don't have to think
hard about the security implications.  (Other than of course about the
implications of *any* reliance on capability bits before msg3/4
signature verification.)

Ian.