[noise] Protocol Names

[Trevor Perrin]

On Tue, May 30, 2017 at 12:09 PM, Alex <alex at centromere.net> wrote:
> On Tue, 30 May 2017 05:23:42 +0000
> Trevor Perrin <trevp at trevp.net> wrote:
>
>> Here are some benefits to having a single representation for a Noise
>> protocol, instead of two:
>>
>>  * We don't have to maintain two grammars, one for JSON and one for
>> protocol names.  For example, consider the current JSON for test
>> vectors:
>>
>> https://github.com/noiseprotocol/noise_wiki/wiki/Test-vectors
>>
>> We'd have to extend this for additional modifiers, e.g. for "noidh",
>> or "sig", and depending on how we do that, the library might have to
>> figure out the order of modifiers itself.
>>
>> That seems like a lot of redundant specification effort, considering
>> we're encoding this information unambiguously in the protocol name.
>>
>
> The handshake pattern naming scheme as defined is not capable of
> expressing perfectly valid patterns like the following:
>
> Noise_???(s, rs):
>    <- s
>    ...
>    -> e, es, s, ss
>    <- e, psk, ee, se

True, but the JSON test vector format isn't capable of expressing that
either, currently.

My argument boils down to wanting one change for something like this
(to protocol naming) instead of two (protocol naming, and JSON).

I think your argument is becoming clearer, though:  Are you thinking
of including the explicit pattern in the JSON test vector format, so
that modifiers that only rearrange patterns can be added without
needing changes to the testing code, by separately specifying the
pattern name and the explicit pattern?

That's worth discussing, though at the moment we have names for the
patterns people want to use, and it's not hard to name other patterns
that become important, so I'm not sure how useful that is.

For the common case of patterns with specified names, this seems more
error-prone, not less (since the JSON would be specifying the same
thing in 2 ways).

I think you earlier suggested deriving the names from the explicit
patterns (e.g. by hashing), but that breaks compatibility and
sacrifices the legibility of the current naming scheme, so I'm not
seeing benefits to that that are worth the cost.


>>  * Focusing on the protocol name I think would encourage an ecosystem
>> of interoperable tools (like code generators, test generators,
>> security analyzers), since people would be steered towards a single
>> format for describing Noise protocols, instead of having to convert
>> between multiple formats.
>>
>
> I too would like to see an ecosystem of interoperable tools, however
> the usefulness of these tools is limited inherently by the
> expressiveness of the pattern naming scheme.

It's true that some tools might need to work with explicit patterns,
and Rhys has started in that direction:

https://github.com/noiseprotocol/noise_spec/tree/master/patterns

I guess my point is that we already have 2 languages (handshake
patterns; protocol names).  I think they're working pretty well, and
have a good division of labor (patterns make it easy to visualize and
reason about the processing steps, and names give a more concise and
high-level description of the pattern, and flesh out the crypto).

So I think we should leverage these languages as much as possible, and
not create additional ways of encoding the same information.

This is an interesting discussion, but if you'd still like to change
things I'd like to see proposals fleshed out in more detail, so we can
weigh costs and benefits.


Trevor