[noise] Protocol Names

[Trevor Perrin]

On Fri, May 26, 2017 at 4:31 PM, Jake McGinty <me at jake.su> wrote:
> As it stands, the current proposal for protocol name formatting leaves open some ambiguities and complications for implementers. Mainly:

Great thoughts, thanks for all this!


> * "Noise_XXpsk0+fallback_25519_AESGCM_SHA256" and “Noise_XXfallback+psk0_25519_AESGCM_SHA256” are identical from a protocol perspective. However, their handshake will fail, since the protocol name is used in the hash during initialization. Currently the spec doesn’t clarify on how to normalize differently-ordered-but-equivalent modifier sets.


[Tangential comment:  we haven't yet defined the "fallback" modifier,
just given an example in "XXfallback".  So I'm not sure that
"fallback" and "psk?" tokens will be commutative (order doesn't
matter).  But if not, there will be other such cases, e.g. "psk?" and
"hfs", so your points stand.]

Anyways, a few ideas:

(A) Require (or recommend) that commutative modifiers appear in
alphabetical order.

(B) Normalize the pattern name into alphabetical modifiers prior to
hashing, so that differently-named patterns are still compatible.

(C) Don't do anything - differently named patterns are simply
incompatible, even if the patterns are identical.


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)?


> * Parsing “XXpsk0+fallback” compared to “XX+psk0+fallback” is more obnoxious to implement and more difficult to make forward-compatible (since right now you kind of have to assume there will never be modifiers that start with [IKNX]). I also personally find "XX+psk0+fallback” to be more readable, and also means in the spec we don’t have to say things like “handshake names will always be uppercase, and modifiers will always start with a lowercase character” in order to remain unambiguous.

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

https://github.com/noiseprotocol/noise_spec/blob/master/extensions/ext_hybrid_forward_secrecy.md

(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)

(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.


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.

For DH, cipher, and hash functions, we maybe shouldn't have modifiers,
but should allow multiple values, provided the pattern gives this some
meaning (e.g. hybrid forward secrecy gives meaning to multiple DH
functions):

[DH]
[DH1]+[DH2]
[DH1]+[DH2]+[DH3]

[CIPHER]
[CIPHER1]+[CIPHER2]

You could still use modifier-like naming, e.g. "25519decaf", but
that's just a naming convention, not something that would be
parseable.

?

Trevor