[noise] rev34 draft

[Nadim Kobeissi]

On Thu, Apr 19, 2018 at 5:59 AM, Trevor Perrin <trevp at trevp.net> wrote:

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

I don't have strong feelings about it either. It's the most minor comment
of my three, I believe.


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

I strongly agree with this plan. I think one of the major strengths of the
Noise spec is how it describes the treatment of all tokens as being parsed
into state evolutions in Section 5. I like the coherence of this approach
and think it would be a great idea to focus rev35 on integrating into it as
much as possible the new conceptual additions. If you still see yourself
adding more such conceptual additions beyond rev34 and into rev35, then I
would also approve moving this reorganization to rev36 or rev37. However, I
think it should definitely be done, so as not to deprive the spec of the
opportunity to exploit one of its core strengths.


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

Yes, I agree that my point regarding 11.5 was an overreach. Forget about it.


>
> Trevor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180419/6a2eca70/attachment.html>