[noise] rev34 draft

[Trevor Perrin]

Thanks Nadim,

On Wed, Apr 18, 2018 at 6:02 PM, Nadim Kobeissi <nadim at symbolic.software> wrote:
>
> 1. I think it would be a good idea to expand 7.1.2 to mention that no token
> may occur twice in the same message flight.

I think you're specifically talking about the DH tokens (ee, es, se,
ss)?  This rule is already in effect for public-key tokens (e, s) due
to the current validity check #2 which mandates at most a single
occurrence of a public-key token in a handshake pattern.  Nadim's
proposed rule wouldn't apply to psk tokens, and might not apply to
future tokens.

Specifying this for DH tokens doesn't seem that important.  The
current check #2 means implementations don't have to support
overwriting a public key with a received public key, which is the
reason I added it.  I'm not sure this new rule would save
implementations any particular effort.

So I don't have strong feelings about this - it rules out
harmlessly-redundant protocols, which we could do (cause they're
redundant), or not do (cause they're harmless).

Are there other arguments one way or another?


> 2. Section 9 seems oddly isolated and describes a single token in a way that
> seems artificially distinct from the other tokens. It can likely be (and
> should be) merged into Section 5, which already contains statements
> describing the methodical parsing of every other token that's not a psk
> token.

Merging the psk stuff earlier could be done.  I sort of like it
pulled-out, so the DH stuff and pattern mechanics can be explained and
understood by itself, without having to think about PSKs until later.
But I see the argument for integrating it.

We've also talked about re-organizing some of the security-property
tables into an appendix.

We have a revision 34 on deck with some conceptual additions (compound
protocols, Alice/Bob roles, deferred patterns).  I'd prefer not to
combine this revision with a bunch of simultaneous re-organization
because the diffs would get confusing.

So I'd propose that we leave purely-organizational changes out of
revision 34, and then do a purely organization revision 35 relatively
soon thereafter (next month or two) where we discuss internal
reorganizations of this document such as moving more things to an
appendix, or better-integrating PSK text.


> 3. Probably my least favorite thing about rev33 is the isolation of certain
> validity rules. Since 7.1 already describes validity rules with one being
> necessary to avoid "catastrophic" errors, it makes a lot of sense to also
> merge the "catastrophe"-avoiding validity rules in 9.3 (and perhaps even
> 11.5) into the same section.

9.3 is just a PSK thing, so I'd fold that into the previous point.
11.5 discusses failing to use a half-duplex protocol correctly, but
that's not a pattern thing, so I don't think belongs in Section 7.

Trevor