[noise] rev34 draft

[Nadim Kobeissi]

Another, distinct comment:

I see that rev34 removes the parentheses, which are added to the pattern's
name to indicate key material that is initialized prior to the pattern's
beginning.

While I was actually myself also of the opinion that these parentheses are
redundant, I actually have come to a different conclusion: the name of the
Noise pattern appears to, by coincidence, also act as a "checksum" as to
the handshake pattern's contents. For example, if you had a handshake
pattern named IKpsk1, but with a psk token that appeared at the very
beginning of the first message pattern, then you would know that something
was wrong. The same is true for the parentheses, and also for the letters I
and K at the beginning of this pattern name.

Perhaps this checksum property could be useful to keep and nurture, as it
acts as a useful way to both colloquially and quickly understand the value
and purpose of a Noise pattern to a human observer, and also as a way for a
mechanical observer to quickly perform a sanity check on the handshake
pattern's design. Removing the parentheses would weaken this coincidental
property.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office

On Thu, Apr 19, 2018 at 12:19 PM, Nadim Kobeissi <nadim at symbolic.software>
wrote:

> 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/29ffb49f/attachment.html>