[noise] Extension spec: Signatures

[Nadim Kobeissi]

Dear Trevor,
Thanks again for continuing to engage on what I hope is a fruitful
discussion.

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

Ah, alright, well that's reassuring. I thought that maybe you were hoping
to be more heavy-handed with how these extensions affect the core spec. I
regret the misunderstanding but am nevertheless relieved.

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

Indeed. My hope would be for extensions to be in separate documents even
after they are no longer experimental, and that is why I keep bringing up
this nebulous idea of an "extension system" which, as you point out, I am
certainly not buttressing with many details.

I think this is the point in the conversation where I go quiet and look at
the following things before I open my mouth again:

- The full "hfs" extension as well as all other extensions that I haven't
reviewed yet.
- What it is exactly that I mean by an "extension system" and how to
outline my proposal more concretely. How would it work, etc.

I hope to look more closely into the above two issues starting now, and to
have more pragmatic suggestions in time for the Noise meetup.

I will in tandem continue to think about how to best integrate
extension-type additions to Noise into Noise Explorer.

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


On Wed, Dec 26, 2018 at 5:17 PM Trevor Perrin <trevp at trevp.net> wrote:

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