[noise] Question: Sending ee, es, se, ss more than once?

[David Wong]

These tokens are not triggering any exchanges (unlike `s` and `e`).
These are just telling you to do a Diffie-Hellman key exchange and to
iterate the chaining key. Having them multiple times would just run
the chaining key multiple times and has no real effect. I'd say common
sense is enough and the spec doesn't need to mention this.

David
On Thu, Jun 21, 2018 at 1:59 AM Ximin Luo <ximin at dfinity.org> wrote:
>
> How you respond to the resending should be made clear. I think it's perfectly fine to resend anything more than once for reliability purposes, as long as the endpoints can detect it and make the effect of receiving it idempotent. In otherwords, the protocol state should not change after receiving the same thing multiple times.
>
> OTOH if you launch a new protocol instance after receiving the same thing twice, or fork existing instances' state to respond to duplicate es/se messages or whatever, that's obviously going to have security implications, probably not good ones.
>
> OTOH if you mean sending *different* e values and then mixing that into the protocol state, that also has security implications. You could do it in a way that maintains security but then I wonder what the point is.
>
> X
>
>
> On Sat, Jun 16, 2018 at 2:27 AM, Nadim Kobeissi <nadim at symbolic.software> wrote:
>>
>> Hello everyone,
>> I have a question which is not very important but still probably worth addressing for completeness.
>>
>> The Noise specification (in Section 7.1) specifically disallows sending `s` or `e` more than once by a single party, and this makes perfect sense. However, it does not seem to disallow sending `ee`, `es`, `se` or `ss` more than once.
>>
>> On the upside: I can't spot any security-related disadvantage (or benefit) that can arise from disallowing these tokens to be sent more than once.
>>
>> On the downside: Technically, this makes it so that Noise Handshake Patterns can have an infinitely long handshake phase, which I don't find useful or clean in terms of framework design.
>>
>> I hope this won't open way to a bike-shedding discussion. In my personal opinion, we should disallow sending these tokens more than once, unless there's something that I'm missing.
>>
>> Thank you,
>>
>> Nadim Kobeissi
>> Symbolic Software • https://symbolic.software
>> Sent from office
>>
>> _______________________________________________
>> Noise mailing list
>> Noise at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/noise
>>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise