<div dir="ltr"><div>Dear Trevor,</div><div>Thanks again for continuing to engage on what I hope is a fruitful discussion.</div><div dir="ltr"><br></div><div dir="ltr">>

I'm not proposing changes to the core spec.</div><div dir="ltr">> </div><div dir="ltr">>  I said we might "eventually" make small generalizations or add details </div><div dir="ltr">>  to the core spec's naming rules, based on our experience with the  <br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr">> extension docs.</div><div dir="ltr"><br></div><div>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.</div><div><br></div><div>> Experimenting with new ideas without contaminating the core spec is a</div><div dir="ltr">> good reason for using extension docs.</div><div dir="ltr"><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- The full "hfs" extension as well as all other extensions that I haven't reviewed yet.</div><div>- What it is exactly that I mean by an "extension system" and how to outline my proposal more concretely. How would it work, etc.</div><div><br></div><div>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.</div><div><br></div><div>I will in tandem continue to think about how to best integrate extension-type additions to Noise into Noise Explorer.</div><div><br></div><div dir="ltr">Nadim Kobeissi<div>Symbolic Software <span style="color:rgb(84,84,84);font-size:small">• <a href="https://symbolic.software" target="_blank">https://symbolic.software</a></span></div><div><span style="color:rgb(84,84,84);font-size:small">Sent from office</span></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 26, 2018 at 5:17 PM Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Dec 25, 2018 at 2:00 PM Nadim Kobeissi <nadim@symbolic.software> wrote:<br>
[...]<br>
><br>
> 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.<br>
<br>
I'm not proposing changes to the core spec.<br>
<br>
I said we might "eventually" make small generalizations or add details<br>
to the core spec's naming rules, based on our experience with the<br>
extension docs.<br>
<br>
For example, we might call the DH names section a "Public key<br>
algorithm names section", and discuss how tokens can refer to<br>
different public-key algorithms with numbered suffixes (as in "ekem1",<br>
"sig1", "s1", etc).  That is the main new idea for names introduced by<br>
the hfs and sig specs.<br>
<br>
Alternatively, we might decide this is better described in a separate<br>
document.  Or we might decide this is a bad idea.<br>
<br>
Experimenting with new ideas without contaminating the core spec is a<br>
good reason for using extension docs.<br>
<br>
<br>
> I think that the core spec should only be changed in so far as to integrate an "extension system" that would clearly specify:<br>
><br>
> - A common logic shared by all extensions as to how they affect the name of Noise protocols.<br>
> - 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."<br>
><br>
> 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.<br>
<br>
Your proposal is to stop working on extension docs and rewrite the<br>
core spec to add an "extension system".<br>
<br>
You've provided no details on this "extension system", or how it would<br>
improve the core spec's extensibility (which is already good, IMO).<br>
Unless you have concrete ideas, there's not much to evaluate here.<br>
<br>
Perhaps your concern is that "hfs" and "sig" are taking small bites<br>
out of the larger/more-general problem of notation for<br>
"multi-algorithm protocols" where signatures, DH, and KEMs are<br>
arbitrarily combined?<br>
<br>
That's true, but it's intentional.  Justin and I have been thinking<br>
about more-general notation for more-complex patterns for some time<br>
(see wiki and archive for multi-algorithm handshakes; see the thread<br>
you are responding to.)<br>
<br>
Because of the complexity of a more general notation, I think it makes<br>
sense to tackle "hfs" and "sig" separately in the near-term.  The hfs<br>
and sig specs address major use cases which real users want solutions<br>
for.  Also, they introduce KEM and signature algorithms into Noise,<br>
and handshakes with multiple public-key algorithms.  Thus they give us<br>
a manageable chunk of new cryptography and notation to analyze and<br>
become comfortable with, which we can then build on.<br>
<br>
Anyways, if you'd like to help design or analyze more general notation<br>
for pattern composition and multi-algorithm cases, by all means join<br>
the discussion with Justin and I and help us figure it out.<br>
<br>
If you'd like to analyze new patterns and new cryptography in Noise<br>
(which your tools are suited for), then the ss/noss, sig, and hfs<br>
proposals are good options.<br>
<br>
If you still want some new "extension system" in the core spec, you'd<br>
have to explain in more detail what this means.<br>
<br>
Trevor<br>
</blockquote></div></div>