[noise] rev34 status

[Trevor Perrin]

On Mon, Jun 18, 2018 at 9:13 AM, jake mcginty <me at jake.su> wrote:
>
> On the new deferred patterns: although an appendix is included with the exact patterns definitions, the spec itself is unspecific about how deferred patterns are generated from the fundamentals.
>
> It doesn't strictly define where the authenticating DH operations are moved to from their original position, and the appendix patterns don't seem to follow a consistent pattern (ex: XX1 *prepends* the "es" token to the next message, whereas NK1 *appends* the "es" token to the next message).


Quick description of the logic I think I applied for deferred
patterns, there's definitely some design choices and room for debate
(and I agree we should add text/rationales to spec, at minimum):

 * Auth token (es or se) moved to end of next message; or earlier if
it improved identity-hiding (XX1 and XX1 are the only cases for the
2nd clause).

* se before es if on same line (consistent with existing patterns)

 * ss removed; this is debatable, but I interpreted it as part of the
authentication, and our intention is to defer the authentication.
Also, one use case for the deferred patterns is to prepare for
sign/kem modifiers which can transform se and es, but not ss.  Also,
we can later add a modifier like "ss1" or something that adds ss to
patterns (and this would be useful even with some other non-deferred
patterns).

Trevor