[noise] rev34 draft

[Justin Cormack]

I am not sure the parenthetical notation helped, I used to find it
confusing at first. Other than for fallback patterns it is generally
obvious from the pattern name what keys you need, ie unless there is an N
you need a static key.

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

> 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
>>>
>>
>>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180419/11ac4c7e/attachment.html>