[noise] Rev30 branch

[Trevor Perrin]

On Sat, Jul 2, 2016 at 4:25 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
>
> On Sat, Jul 2, 2016 at 4:23 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>>
>> https://github.com/noiseprotocol/noise_spec/compare/master...rev30
>> https://github.com/noiseprotocol/noise_spec/blob/rev30/noise.md
>> https://github.com/noiseprotocol/noise_spec/blob/rev30/output/noise.pdf
>
>
> A question:
>
> "If any negotiation occurred in the first handshake, the first handshake's `h` variable should be provided as prologue to the second handshake."
>
> What means "any negotiation"?


That sentence was meant to apply to "compound protocols" in general,
not specifically Noise Pipes (which are a type of compound protocol).

For example, consider this non-Pipe "compound protocol":  The first
payload in an XX handshake advertises alternative ciphers the server
can choose.  If the server chooses something different from the
default, the client will re-initialize for a different handshake.

In that case, since the initial handshake message advertised a list of
values that we don't want an attacker to tamper with, it makes sense
to make that handshake's "h" value a prologue to the second handshake.

But in the Noise Pipes case, there's no such context, so we don't need
to do this.


>
>   My test vectors for Noise Pipes have assumed that the original prologue and PSK are passed to the fallback handshake as-is


I think that's the right interpretation.  This definitely needs to be
clarified in spec.


> The IK packet will fail on the "dhes" token in the responder.  By that time, the "h" value will already have been set to something by the previous "e" token.  Is that "h" the value that should be passed to XXfallback as the prologue?


If a compound protocol was chaining the "h" value, I think it would
have to spell this out.


> I think this needs to be clarified.


Yeah, definitely.  Probably Noise Pipes and compound protocols need a
whole top-level section.


>
>
>>  * Some clarification on combining PSK with Noise Pipes, but no-one
>> was doing this, so it also shouldn't affect anything.
>
>
> Well, my noise-c-fallback.txt test vectors were, so they'll need to change. :-)


Sorry about that...


>
>   And if fallback prologues are now all based on "h", then the non-PSK vectors will change too.
>

But no, I think this is fine.

Trevor