[noise] Extension spec: Signatures

[Trevor Perrin]

On Tue, Dec 25, 2018 at 2:00 PM Nadim Kobeissi <nadim at symbolic.software> wrote:
[...]
>
> 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'm not proposing changes to the core spec.

I said we might "eventually" make small generalizations or add details
to the core spec's naming rules, based on our experience with the
extension docs.

For example, we might call the DH names section a "Public key
algorithm names section", and discuss how tokens can refer to
different public-key algorithms with numbered suffixes (as in "ekem1",
"sig1", "s1", etc).  That is the main new idea for names introduced by
the hfs and sig specs.

Alternatively, we might decide this is better described in a separate
document.  Or we might decide this is a bad idea.

Experimenting with new ideas without contaminating the core spec is a
good reason for using extension docs.


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

Your proposal is to stop working on extension docs and rewrite the
core spec to add an "extension system".

You've provided no details on this "extension system", or how it would
improve the core spec's extensibility (which is already good, IMO).
Unless you have concrete ideas, there's not much to evaluate here.

Perhaps your concern is that "hfs" and "sig" are taking small bites
out of the larger/more-general problem of notation for
"multi-algorithm protocols" where signatures, DH, and KEMs are
arbitrarily combined?

That's true, but it's intentional.  Justin and I have been thinking
about more-general notation for more-complex patterns for some time
(see wiki and archive for multi-algorithm handshakes; see the thread
you are responding to.)

Because of the complexity of a more general notation, I think it makes
sense to tackle "hfs" and "sig" separately in the near-term.  The hfs
and sig specs address major use cases which real users want solutions
for.  Also, they introduce KEM and signature algorithms into Noise,
and handshakes with multiple public-key algorithms.  Thus they give us
a manageable chunk of new cryptography and notation to analyze and
become comfortable with, which we can then build on.

Anyways, if you'd like to help design or analyze more general notation
for pattern composition and multi-algorithm cases, by all means join
the discussion with Justin and I and help us figure it out.

If you'd like to analyze new patterns and new cryptography in Noise
(which your tools are suited for), then the ss/noss, sig, and hfs
proposals are good options.

If you still want some new "extension system" in the core spec, you'd
have to explain in more detail what this means.

Trevor