[noise] Generating patterns, and ss tokens

[Justin Cormack]

On 22 June 2018 at 03:08, Trevor Perrin <trevp at trevp.net> wrote:
> Here is another wrinkle:  it's easy to change the draft 34 and add
> "ss" back into, say, K1K (or I1K).
>
> But it's not so easy to add "ss" back into KK1 and K1K1 (or IK1 and
> I1K1), due to the validity rule I was just discussing with Karthik.
> KK1 and K1K1 would defer the authentication from the first message,
> and Noise doesn't let you send a message relying only on static-static
> DH for authenticating the recipient, when you are capable of an
> ephemeral-static DH.

yes, and my generation rules include that rule (I have an idea to make them
more readable now for the appendix)

> 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.

> So given this, would we still want to add the ss into K1K and I1K, or
> leave it out?  Adding it makes KK and K1K more similar, but leaving it
> out makes all the deferred patterns more similar...

What I like about the rule generation is that the similarity is just a byproduct
of the simple rules and the fact that the same tokens are available, but there
is no requirement forcing similarity. The similarity that does fall
out is that the
first lines are either -> e, es, ss or  -> e, es, s, ss for the use of
ss, which is
not a property related to deferral at all.

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.

Justin