<div dir="ltr"><div dir="ltr"><div dir="ltr">I have been working on integrating signatures into Noise Explorer.</div><div dir="ltr"><div><br></div><div>I am in an awkward position because I believe that my position as steward for Noise Explorer may be harmed by my allowing myself to be opinionated about the Noise Protocol Framework. I think it's clear that in order to carry my task most effectively, making sure that the Noise Protocol Framework is continually formally verified as it evolves, I should as much as is possible not join the more speculative discussions but simply take what is specified and formally analyze it impartially.</div><div><br></div><div>That said, I think it's time I made an effort to write as impartially and carefully as possible what I believe are issues with the Noise Protocol Framework that I would much like to see addressed, because they are not small and I think are attacking some of the finer temperaments of the framework.</div><div><br></div><div>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 a new reality has to be embraced where either:</div><div>    a) Names are separated into Names and Extensions. Instead of "NKsig", we have "NK with extensions: sig."</div><div>    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.</div><div>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.</div><div>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!</div><div>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.</div><div><br></div><div>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.</div><div>    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.</div><div>    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.</div><div><br></div><div>3. Signatures further integrate the logic of cipher suites into the Noise Protocol Framework. I think everyone on this list is already aware of the arguments regarding cipher suites, so I won't go into that. I simply don't think that's a good direction and would have preferred for Noise to avoid it instead of committing further to it. Versioning should instead be considered. <br></div><div><br></div><div>4. Section 5 paragraph 2 should be rewritten entirely. It's very bad.</div><div>    a) A Noise Handshake Pattern named "XXhfs_sig" is mentioned. This is strange. What does "hfs" stand for? Where was this name/token defined? Or is this actually a "protocol name?" (that would at least explain the underscore ("_")). Where do I go for a reliable, precise, complete reference to all these "names" and tokens" whose hierarchy to one another is clearly delineated? *Emphatically points at point 1 of this email, again*</div><div>    b) Cipher suites are predicated on arbitrary suffixes to tokens in Noise Handshake Pattern names, in contravention to how all other cipher suites are specified and namespaced (see comments re. Section 8 in point 1.)</div><div><br></div><div>More generally, the complexity that seems to be shot for in this paragraph, coupled with a severely lacking namespacing and organizational philosophy, does not bode well for Noise's progress. There is a degradation in elegance that flies in a completely in the different direction from the simplicity that I believe was largely responsible for winning Noise a following. For example, David Wong almost entirely defended the viability of his recent work [1] based on this elegance, simplicity and restricted state space that Noise has had historically.</div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><div>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. The framework must be made more explicitly modular in order to avoid what I would deem an unfortunate overloading of the current token space and name space and an eccentric increase in the complexity of an arbitrary Noise Handshake Pattern design. I am of course happy to work on this and offer practical suggestions based on direct edits to revision 34. This should be a main focus for revision 35! </div><div><br></div><div>References:</div><div>[0] <a href="https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf">https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf</a> (version dated 2018-12-17.)</div><div>[1] <a href="https://cryptologie.net/article/446/quic-crypto-and-simple-state-machines/">https://cryptologie.net/article/446/quic-crypto-and-simple-state-machines/</a></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><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 18, 2018 at 11:48 AM Justin Cormack <<a href="mailto:justin@specialbusservice.com">justin@specialbusservice.com</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, 18 Dec 2018 at 06:46, Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>> wrote:<br>
><br>
> On Mon, Dec 17, 2018 at 1:24 PM Justin Cormack<br>
> <<a href="mailto:justin@specialbusservice.com" target="_blank">justin@specialbusservice.com</a>> wrote:<br>
> ><br>
> > Hi, I was writing up the version I discussed before which is designed<br>
> > to support pattern composition (that I also need to finish writing<br>
> > up). The differences are as follows.<br>
> ><br>
> > There are 11 basic signature patterns (all the basic patterns except<br>
> > NN). As the deferral is implicit, I named them without the numbers,<br>
> > although that is a matter of taste. These correspond to your patterns<br>
> > with both es and se replaced:<br>
><br>
> OK cool, I made a revision 2 where "sigi" and "sigr" modifiers are<br>
> removed, so my spec only contains these 11 patterns where all<br>
> authentication DHs can be replaced with signatures.<br>
><br>
> <a href="https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf" rel="noreferrer" target="_blank">https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf</a><br>
><br>
> I think that's simple and useful functionality we could hopefully<br>
> agree on while we continue to work out more complicated cases.<br>
<br>
Definitely.<br>
<br>
> I did name these with the deferred "1" numbers, so that the "sig"<br>
> modifier has to do less work.  I think you have a more "generative"<br>
> viewpoint, but I like to be able to read simple "transformations" from<br>
> one pattern to another.<br>
<br>
Yes I wasn't sure about the simplification, no harm in being more explicit.<br>
<br>
><br>
> > I also used "+" in the pattern naming ie<br>
> > Noise_IKsig_25519+Ed25519_AESGCM_SHA256 to make it clearer how to<br>
> > parse the names, and I think this works best with the composition<br>
> > rules although these need finalising. Using underscore the parsing is<br>
> > more implicit. The<br>
><br>
> I didn't understand this paragraph, it got cut off?<br>
<br>
Lets leave this now, I think it makes sense with the other combination rules<br>
but lets review these first. It just groups the DH and DH like algorithms; in<br>
some future case where there is a pair of hash functions say it may be clearer.<br>
<br>
><br>
> > Your additional patterns are then combinations. The combination rules<br>
> > are quite simple, for "i" patterns you use N.+.Nsig ie the sig<br>
> > modifier is applied to something that only has initiator keys, and the<br>
> > opposites.<br>
> ><br>
> > XKsigi is<br>
> > NK+XNsig:<br>
> >   <- s<br>
> >   ...<br>
> >   -> e, es<br>
> >   <- e, ee<br>
> >   -> s1, sig1<br>
><br>
> For the cases with mixed DH and signature authentication, I would<br>
> definitely like to see your "pattern composition" approach fleshed<br>
> out.  Some questions I have about it:<br>
><br>
>  * It's not obviously more readable, i.e. looking at above example:<br>
> XKsigi can be read and applied quite easily:  just take XK and replace<br>
> the initiator auth with a signature.  Viewing this as NK+XNsig takes<br>
> more thinking to "merge" 2 different patterns.<br>
<br>
Not obviously more readable, but I think the benefits of being more general<br>
and working for other combinations but lets see. I am interested in patterns<br>
like KK+XXsig for example.<br>
<br>
>  * If "pattern composition" automatically merges ephemeral, how would<br>
> we handle cases where we want to add or replace ephemerals, e.g.<br>
> hybrid forward secrecy?  If we're tackling a general composition<br>
> mechanism it probably needs to be able to combine DH, signatures, and<br>
> ephemeral or static KEMs, arbitrarily.<br>
<br>
Yes, I will need to make these cases clear.<br>
<br>
> > XXsigr is also valid, which is XN+NXsig, and XXsigi which is NX+XNsig<br>
> > - you didn't need to use the deferred patterns for the XX ones as<br>
> > XXsig is valid. K1K1sigi and K1K1sigr are also valid, and K1Xsigi and<br>
> > K1Xsigr, and I1K1sigi and I1K1sigr. So overall there are I think 8<br>
> > patterns that you miss that are valid, giving 31 patterns overall.<br>
><br>
> I only included sigi/sigr if sig wasn't possible, but that was kind of<br>
> an arbitrary choice.  Also including sigi+sigr patterns would make<br>
> sense, to allow for different types of signature algorithms.<br>
><br>
> > This is significantly more complex as a spec than my version with just<br>
> > 11 patterns plus composition rules to make up the other versions, so<br>
> > long as you agree the composition rules are simple (and I think they<br>
> > are otherwise useful). I will do a writeup of the composition rules<br>
> > this week.<br>
><br>
> I'm not sure the composition rules are simple yet, but they're<br>
> definitely intriguing, particularly if they extend to handling other<br>
> cases.<br>
><br>
> Trevor<br>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div>