[noise] NoiseSocket - next steps

[Trevor Perrin]

On Fri, Mar 10, 2017 at 1:54 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
>
>
> On Sat, Mar 11, 2017 at 7:24 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> The idea that was bandied about earlier was to use the list of all
>> client-offered protocol names as the prologue.
>>
>> That doesn't bind the message contents for non-chosen client initial
>> messages, but I think that's OK, though merits a security
>> consideration (server should only inspect protocol names, not
>> messages, when choosing which message to respond to).
>
>
> There is a scenario where message contents could be relevant.  I give you
> NoisePipesNG:
>
> - The initiator includes both IK and XX protocols in its handshake with the
> same crypto algorithms.
> - IK is listed first as preferred over XX.
> - The IK and XX protocols may share the same ephemeral.
> - The responder tries to use IK and it fails.
> - The responder immediately shifts to XX (a real XX handshake, not
> XXfallback) and reports that as its chosen protocol.

We'd have to disallow that, the server would be required to first
choose the handshake message it's responding to (IK), and then do
XXfallback if it wants.

That doesn't seem terrible, compared to alternative:

As you point out, we can't resolve the circular dependency in the
client's first message, since a bunch of different zero-RTT
encryptions can't all bind each other's final ciphertext.

So the best that can be done seems to be holding a hash value or
something over the entire initial client message, and binding that
hash in the server's response as a "belated prologue" or something.

But that doesn't protect the initial client message, so in your case
above it's still possible to get the server to accept an initial XX if
the IK is tampered with, it's just that the client detects it
afterwards.

So that's still a confusing security story which doesn't perfectly
solve the underlying problem.  And it's a complicated mechanism, since
now the client has to hold some extra data and hash a "belated
prologue" in some cases.

I think I'm skeptical that small change to the security story is worth
the complexity.

Trevor