[noise] Generating patterns, and ss tokens

[Trevor Perrin]

On Fri, Jun 22, 2018 at 8:19 AM, Justin Cormack
<justin at specialbusservice.com> wrote:
> On 22 June 2018 at 03:08, Trevor Perrin <trevp at trevp.net> wrote:
>
>> In this case, the validity rule isn't protecting you from any replay
>> attack (I think), so we could consider rejiggering the validity rule
>> to allow the "ss" here.  But I like Noise's strictness: if you can do
>> an ephemeral-static DH it's a bad idea to rely on a static-static DH
>> instead.
>
> Yes, I prefer strictness here too.

Also I was wrong: the validity rule *does* protect against key reuse
here, since sending "e, ss" as a first message in KK1 would reuse the
same key.


> The tidied rules are below (will tidy up a bit more and add a new
> explan), but they are
> all pretty obvious.
>
> Initiator
> 1. Send e immediately
> 2. Perform ee as soon as possible
> 3. Perform se as soon as possible if not deferred. If initiator
> deferred, skip this rule on the first line it applies
> 4. Perform es as soon s possible if not deferred. If responder
> deferred, skip this rule on the first line it applies
> 5. Perform ss if we cannot perform se on the first line but have done es
> 6. if initiator is "I" or is one way "X", send s as soon as possible
> 7. if initiator is "X", send s if not on first line
>
> Responder
> 1. Send e immediately
> 2. Perform ee as soon as possible
> 3. Perform se as soon as possible if not deferred. If initiator
> deferred, skip this rule on the first line it applies
> 4. Perform es as soon s possible if not deferred. If responder
> deferred, skip this rule on the first line it applies
> 5. if responder is "X", send s as soon as possible
>
> If you remove the "on the first line" part of the ss rule, it makes no
> sense as it will do an ss instead of a deferred
> operation, which kind of misses the point of deferral.

That's looking good..

OK, so you like adding "ss" to the first message in X1K and I1K but
not the other deferred patterns.  I think that makes sense, it could
be interpreted as deferring the authentication DH, then removing the
ss if it would make an invalid pattern.

Also I think we're agreed that we should have modifiers to add/remove
ss, so what we're discussing for X1K/I1K is defaults and naming more
than functionality, this isn't the most critical decision.

But I'll try this in the rev34 draft when I have time (maybe this weekend).

Trevor