[noise] Spec revision 32

[Alex]

On Fri, 19 May 2017 14:55:02 +0200
"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> On Fri, May 19, 2017 at 2:40 PM, Alex <alex at centromere.net> wrote:
> > That solution couples the *meaning* of the `e` token with some
> > arbitrary string provided by the user (the handshake name), which I
> > argue is worse, because now I have to validate that the user didn't
> > make a mistake by forgetting to add "psk" to the pattern name after
> > they add a `psk` token -- which requires me to perform a static
> > analysis anyway.
> >
> > Or I could just require that the user not make any mistakes and
> > provide no degree of safety whatsoever.  
> 
> I believe the intention behind named handshakes is to not allow the
> user to provide the pattern in the first place, and instead simply
> give a menu of preexisting named handshakes.
> 

`psk` tokens can be placed anywhere, possibly multiple times, and still
constitute a valid pattern. The naming scheme is not capable of
expressing every possible valid pattern, so it doesn't make sense to
treat it as anything other than an arbitrary string provided by the
user.

I will provide off-the-shelf patterns for people, but I think it's also
important to allow the user can define their own pattern if they choose
to do so.

> If you're going to depart from this and allow the user to provide
> arbitrary token sequences, you'll need to scan the whole thing,
> anyway, to ensure that various other pattern validity rules aren't
> being violated. In that case, too, you'll learn about the existence of
> psk.

Ideally pattern validation would be optional for performance reasons. In
this case it's required (at the very least to check for the presence of
the `psk` token).

So when I asked, "Is this correct?" it sounds like the answer is "Yes".

-- 
Alex