[noise] Extension spec: Signatures

[Trevor Perrin]

Hi Nadim,

Thanks for your feedback.  Keep in mind the newer specs ("ss", "sig",
hfs") are "unofficial" and "unstable".

So it's a great time to be critiquing these designs, exploring
alternatives, and analyzing their security.

You're worrying a lot here about editorial aspects and document
organization.  It's true these new specs lack polish and introduce new
ideas that aren't integrated into the core spec yet.  But that's
exactly the point of these extensions:  to let us explore new ideas
*without* impacting the core spec.

So I'm happy to discuss these proposals, but hopefully we can focus on
their substance, and on concrete ideas for improvements or
alternatives.


On Mon, Dec 24, 2018 at 1:37 PM Nadim Kobeissi <nadim at symbolic.software> wrote:
>
> 1. The naming convention for Noise Handshake Patterns is no longer tenable. We now have modifiers that are longer and more descriptive than the name of the patterns themselves ("sig" versus "NK", "noss" versus "IK", etc. I have a feeling this started with the "psk" modifier but has been allowed to grow inappropriately.)

I think our naming system of BASENAMEmodifier+modifier+... is working
well for "psk", "hfs", "sig", "ss", etc.

It's not clear what you dislike about it.  You mention that modifier
names have more characters than base pattern names, but I don't see
why that matters.


> I think a new reality has to be embraced where either:
>     a) Names are separated into Names and Extensions. Instead of "NKsig", we have "NK with extensions: sig."
>     b) Names are made more descriptive. "NK" is replaced with something that is still concise but that more intuitively captures what this pattern is about.

We're not going to rename existing patterns from the core spec.  The
core spec is largely stable (with an exception for the recently-added
"deferred" patterns).  We won't make changes that break compatibility
with the stable parts.


> Perhaps the bigger issue is that Section 8 of the Noise Protocol Framework specification, which is dedicated to naming conventions, is a mess and seems to be falling way behind all of the new extensions and additions that have been popping up.
> Section 8 describes many different unintuitive namespaces that are detached from the actual evolution of the Noise Protocol Framework: notice for example that Diffie-Hellman cipher suites are defined by the "protocol name", while signature cipher suites are defined by an arbitrary number suffixing a token in the Handshake Pattern name!
> I think that especially with these new extensions, the entire naming philosophy for the Noise Protocol Framework needs to be completely rebuilt from scratch into something more intuitive, uniform and elegant. I don't like where this is going at all and I think it's time there was a serious cleanup effort with how patterns are named and organized.

Section 8 of the core spec explains the existing naming rules well, I think.

The "sig" and "hfs" specs extend the core spec's naming rules, in
particular they introduce tokens with a numbered suffix that refers to
different public-key algorithms in the "DH" name section:

Noise_XXhfs_25519+NewHope_...
 (adds "e1" and "ekem1")

Noise_XXsig_25519+Ed25519_...
 (adds "s1" and "sig1")

Noise_XXhfs+sig_25519+NewHope+Ed25519_...
 (adds "e1", "ekem1", "s2", and "sig2")

If this turns out to be a good idea then we can (eventually!)
generalize the core spec to account for that.  Call this the "public
key algorithms" name section rather than the "DH section", and discuss
suffix numbers and so on.

If this is not a good idea then I'd like to hear concrete proposals
for better ideas.

The main concern I have about above proposals is that they seem to be
special cases of a more general/eventual set of rules for combining
DH, signatures, and KEMs arbitrarily.

Justin and I have been discussing what those more general rules would
be like, so feel free to join those discussions if you'd like to help
generalize and rethink pattern naming.


> 2. Generally, the description of signatures is done such that is it too relative to and dependent on how DH operations were described in the original specification, instead of running in parallel to that description.

The signatures spec was written quickly as a delta to the core spec.
I'm sure it could be polished, and I'll clear up things that are
ambiguous, but let's focus on the ideas and mechanisms there.


>     a) [0] does not specify what exactly happens to the GENERATE_KEYPAIR function once a "sig" modifier or token is included in a Noise Handshake Pattern. Does it fundamentally change to produce signature key pairs instead of Diffie-Hellman key pairs? This is what I am assuming but it is significant and not mentioned anywhere that I can see.

Nothing about that is changed.  GENERATE_KEYPAIR is used to generate
ephemeral key pairs, which are not affected by the "sig" modifier.


>     b) [0]'s method of describing the how signature key exchange works is too dependent on substitution with DH key exchange logic. It's much better to again revise the entire spec to present the two modes more elegantly, in parallel to one another, and this would very much go hand in hand with the namespacing improvements I encourage in point 1.

Again, seems like you want editorial improvements which aren't a
priority right now.  If you have trouble understanding the doc let me
know what needs to be clarified.  But it's a simple mechanism:  in
place of "es" and "se" we send signatures from the static key over the
"h" value.

Is that a good idea?  Is it secure?  These are questions worth
addressing, and which Noise Explorer could help with.  But rewriting
the presentation to be more "elegant" is low on my priority list.

>     a) A Noise Handshake Pattern named "XXhfs_sig" is mentioned.

Typo, meant "XXhfs+sig", fixed.

> This is strange. What does "hfs" stand for?

Hybrid forward-secrecy, you can find the spec linked from wiki.


> I would strongly recommend, before the signature extension or any other extension moves forward, that the issues I discuss above be tackled directly, especially a complete rewriting of Section 8 of the Noise Protocol Framework specification.

If things like "hfs" and "sig" are good ideas, and we develop more
sophisticated "pattern composition" rules, then we can change the core
spec to account for them.  But we're not there yet, so the task for
the moment is to assess these ideas, and keep anything
experimental/unstable away from the core spec.

Trevor