<div dir="ltr"><div dir="ltr"><div>Dear Trevor,</div><div><br></div><div>Thank you very much for your detailed response.</div><div><br></div><div>> You're worrying a lot here about editorial aspects and document organization.</div><div>> [...]</div><div>> 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.</div><div><br></div><div>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:</div><div><br></div><div>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:</div><div><br></div><div>- A common logic shared by all extensions as to how they affect the name of Noise protocols.</div><div>- 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."</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div><div>> 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.</div><div><br></div><div>Of course, that makes perfect sense.</div><div><br></div><div>> Nothing about that is changed.  GENERATE_KEYPAIR is used to generate ephemeral key pairs, which are not affected by the "sig" modifier.</div><div><br></div><div>Ah, of course, you're right.</div><div><br></div><div>> Hybrid forward-secrecy, you can find the spec linked from wiki.</div><div><br></div><div>Got it, thank you: <a href="https://github.com/noiseprotocol/noise_wiki/wiki/Hybrid-Forward-Secrecy">https://github.com/noiseprotocol/noise_wiki/wiki/Hybrid-Forward-Secrecy</a></div><div><br></div><div>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.</div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><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></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 24, 2018 at 10:19 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">Hi Nadim,<br>
<br>
Thanks for your feedback.  Keep in mind the newer specs ("ss", "sig",<br>
hfs") are "unofficial" and "unstable".<br>
<br>
So it's a great time to be critiquing these designs, exploring<br>
alternatives, and analyzing their security.<br>
<br>
You're worrying a lot here about editorial aspects and document<br>
organization.  It's true these new specs lack polish and introduce new<br>
ideas that aren't integrated into the core spec yet.  But that's<br>
exactly the point of these extensions:  to let us explore new ideas<br>
*without* impacting the core spec.<br>
<br>
So I'm happy to discuss these proposals, but hopefully we can focus on<br>
their substance, and on concrete ideas for improvements or<br>
alternatives.<br>
<br>
<br>
On Mon, Dec 24, 2018 at 1:37 PM Nadim Kobeissi <nadim@symbolic.software> wrote:<br>
><br>
> 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.)<br>
<br>
I think our naming system of BASENAMEmodifier+modifier+... is working<br>
well for "psk", "hfs", "sig", "ss", etc.<br>
<br>
It's not clear what you dislike about it.  You mention that modifier<br>
names have more characters than base pattern names, but I don't see<br>
why that matters.<br>
<br>
<br>
> I think a new reality has to be embraced where either:<br>
>     a) Names are separated into Names and Extensions. Instead of "NKsig", we have "NK with extensions: sig."<br>
>     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.<br>
<br>
We're not going to rename existing patterns from the core spec.  The<br>
core spec is largely stable (with an exception for the recently-added<br>
"deferred" patterns).  We won't make changes that break compatibility<br>
with the stable parts.<br>
<br>
<br>
> 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.<br>
> 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!<br>
> 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.<br>
<br>
Section 8 of the core spec explains the existing naming rules well, I think.<br>
<br>
The "sig" and "hfs" specs extend the core spec's naming rules, in<br>
particular they introduce tokens with a numbered suffix that refers to<br>
different public-key algorithms in the "DH" name section:<br>
<br>
Noise_XXhfs_25519+NewHope_...<br>
 (adds "e1" and "ekem1")<br>
<br>
Noise_XXsig_25519+Ed25519_...<br>
 (adds "s1" and "sig1")<br>
<br>
Noise_XXhfs+sig_25519+NewHope+Ed25519_...<br>
 (adds "e1", "ekem1", "s2", and "sig2")<br>
<br>
If this turns out to be a good idea then we can (eventually!)<br>
generalize the core spec to account for that.  Call this the "public<br>
key algorithms" name section rather than the "DH section", and discuss<br>
suffix numbers and so on.<br>
<br>
If this is not a good idea then I'd like to hear concrete proposals<br>
for better ideas.<br>
<br>
The main concern I have about above proposals is that they seem to be<br>
special cases of a more general/eventual set of rules for combining<br>
DH, signatures, and KEMs arbitrarily.<br>
<br>
Justin and I have been discussing what those more general rules would<br>
be like, so feel free to join those discussions if you'd like to help<br>
generalize and rethink pattern naming.<br>
<br>
<br>
> 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.<br>
<br>
The signatures spec was written quickly as a delta to the core spec.<br>
I'm sure it could be polished, and I'll clear up things that are<br>
ambiguous, but let's focus on the ideas and mechanisms there.<br>
<br>
<br>
>     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.<br>
<br>
Nothing about that is changed.  GENERATE_KEYPAIR is used to generate<br>
ephemeral key pairs, which are not affected by the "sig" modifier.<br>
<br>
<br>
>     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.<br>
<br>
Again, seems like you want editorial improvements which aren't a<br>
priority right now.  If you have trouble understanding the doc let me<br>
know what needs to be clarified.  But it's a simple mechanism:  in<br>
place of "es" and "se" we send signatures from the static key over the<br>
"h" value.<br>
<br>
Is that a good idea?  Is it secure?  These are questions worth<br>
addressing, and which Noise Explorer could help with.  But rewriting<br>
the presentation to be more "elegant" is low on my priority list.<br>
<br>
>     a) A Noise Handshake Pattern named "XXhfs_sig" is mentioned.<br>
<br>
Typo, meant "XXhfs+sig", fixed.<br>
<br>
> This is strange. What does "hfs" stand for?<br>
<br>
Hybrid forward-secrecy, you can find the spec linked from wiki.<br>
<br>
<br>
> 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.<br>
<br>
If things like "hfs" and "sig" are good ideas, and we develop more<br>
sophisticated "pattern composition" rules, then we can change the core<br>
spec to account for them.  But we're not there yet, so the task for<br>
the moment is to assess these ideas, and keep anything<br>
experimental/unstable away from the core spec.<br>
<br>
Trevor<br>
</blockquote></div>