[noise] Protocol Names

[Jake McGinty]

> On May 27, 2017, at 2:06 AM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> I think (B) is the least attractive, since it complicates things to
> have libraries applying a normalization algorithm, and the library
> would have to know which modifiers commute.
> 
> I guess I'd lean towards (A) as a recommendation, or (C)?

I agree that there’s probably something that’s gone awry if a cryptographic library has to worry about alphabetic ordering.

However, looking at other Noise implementations, many currently take in a set of enumerated protocol choices and *generate* a protocol name string from those choices, rather than taking a protocol name string and parsing them into enumerated choices and modifiers. So, some recommendation for normalizing the outputted protocol name may be important unless libraries all move toward taking a string as input.

Personally, it seems totally reasonable to simply recommend a convention like alphabetical order, with a "while this ordering is not a requirement, protocol names must be identical for a successful handshake" or something like that.

> Good points, other wrinkles:
> 
> (1) It's unclear how all this interacts with "hfs" naming, where we
> were thinking of using a plus to separate pairs of algorithms, but
> these aren't really modifiers, e.g.
> 
> Noise_XXhfs_25519+448_AESGCM_SHA256

In this case the “+” token carries two usages (which is fine, they don’t conflict… yet) depending on the context. It’s used in handshakes for multiple modifiers (where you’ll never see XX+NN, anyway), but in crypto primitive choices it's for the multiple algorithms case. Howeverrrrrrr,


> (2) It's not clear that it makes sense to apply modifiers to DH,
> ciphers, and hash functions.  Though as a though experiment, we could
> imagine things like:
> * 25519strict, 25519decaf (stricter parsing; different encoding)
> * SHA512nohkdf (but note that not all cipher/hash names end in uppercase)

If I wanted strict and decaf, we would just use 25519strictdecaf which is only 3 permutations, but if another modifier like “elligator” (forgive me if that’s not an applicable example in this case) came around, it could get hairy quickly.

> (3) Note that "XXfallback" and "IKpsk2" are deployed (WhatsApp,
> WireGuard), so it would be a big deal to break compatibility here, and
> we probably can't do it.

Yep, makes sense!

> 
> 
> Given all this, I'm thinking that modifiers might only apply to
> pattern names, and would use the syntax:
> 
> [BASENAME]
> [BASENAME]mod1
> [BASENAME]mod1+mod2+mod3
> 
> I can see the argument for "[BASENAME]+mod1", but
> history/compatibility argues against it.  And it's sort of nice that
> the common case of a single modifier is writeable without special
> characters (IKpsk2), so this isn't a horrible syntax.
> 
> If BASENAMES are uppercase, and modifiers are lowercase, this is parseable.

Cool, guaranteeing that BASENAMES are uppercase and mods are lowercase now and in the future seems like the easiest way to ensure parseability and remain backwards compatible with existing deployments.