[noise] Extension spec: Signatures

Tue Dec 25 06:00:44 PST 2018

Dear Trevor,

Thank you very much for your detailed response.

> You're worrying a lot here about editorial aspects and document
organization.
> [...]
> 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. [...] 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.

It is indeed true that I am worrying about aspects of document organization
and I am aware of this. However, this is not the full depth of my concern,
so let me explain properly:

Right now, you are proposing to "change the core spec" to account for
extensions. This is precisely what I would like for Noise to avoid. I think
that the core spec should only be changed in so far as to integrate an
"extension system" that would clearly specify:

- A common logic shared by all extensions as to how they affect the name of
Noise protocols.
- A common logic shared by all extensions as to how they affect a core
protocol logic (state logic, key management, what have you, depending on
what the extension is for) through a common "extension API."

What I am proposing, thus, is to put a moratorium on the discussion of
extensions themselves until the Noise Protocol Framework specification
itself is revised such that support for these eventual extensions can be
integrated uniformly and elegantly.

Then, you can decide to freeze the Noise Protocol Framework specification
for some unbounded length of time, and write "sig", "psk" and "hfs" purely
as extensions that never need any revisions be applied to the core spec!

So, later, when someone writes a "sig" extension, if it uses the extension
system explained in the core spec, it would be immediately pluggable into
the Noise Protocol Framework. Then, alternatively, if someone wanted to use
Noise with no extensions at all in order to maintain its simplicity and
elegance as a protocol framework, they can do so just fine without loading
any extension! It's the best of both worlds!

I am confident my proposal is a good one. My concern is that if this is not
performed prior to continued discussion with regards to extensions, then
the entire process of discussing, verifying and integrating these
extensions will be significantly more expensive and result in more
complications that will be more cumbersome to eliminate after the fact,
rather than before, and that the Noise Protocol Framework will become more
complex for *all* of its users, unnecessarily.

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

Of course, that makes perfect sense.

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

Ah, of course, you're right.

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

Got it, thank you:
https://github.com/noiseprotocol/noise_wiki/wiki/Hybrid-Forward-Secrecy

I understand and agree with the rest of your email. My main point is the
one I make above at the beginning of this reply.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office

On Mon, Dec 24, 2018 at 10:19 PM Trevor Perrin <trevp at trevp.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20181225/2c5d438e/attachment.html>