[noise] Extension spec: Signatures

Mon Dec 24 05:36:51 PST 2018

I have been working on integrating signatures into Noise Explorer.

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.

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.

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:
    a) Names are separated into Names and Extensions. Instead of "NKsig",
we have "NK with extensions: sig."
    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.
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.
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!
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.

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

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.

4. Section 5 paragraph 2 should be rewritten entirely. It's very bad.
    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*
    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.)

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.

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!

References:
[0]
https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf
(version dated 2018-12-17.)
[1]
https://cryptologie.net/article/446/quic-crypto-and-simple-state-machines/

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

On Tue, Dec 18, 2018 at 11:48 AM Justin Cormack <
justin at specialbusservice.com> wrote:

> On Tue, 18 Dec 2018 at 06:46, Trevor Perrin <trevp at trevp.net> wrote:
> >
> > On Mon, Dec 17, 2018 at 1:24 PM Justin Cormack
> > <justin at specialbusservice.com> wrote:
> > >
> > > Hi, I was writing up the version I discussed before which is designed
> > > to support pattern composition (that I also need to finish writing
> > > up). The differences are as follows.
> > >
> > > There are 11 basic signature patterns (all the basic patterns except
> > > NN). As the deferral is implicit, I named them without the numbers,
> > > although that is a matter of taste. These correspond to your patterns
> > > with both es and se replaced:
> >
> > OK cool, I made a revision 2 where "sigi" and "sigr" modifiers are
> > removed, so my spec only contains these 11 patterns where all
> > authentication DHs can be replaced with signatures.
> >
> >
> https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf
> >
> > I think that's simple and useful functionality we could hopefully
> > agree on while we continue to work out more complicated cases.
>
> Definitely.
>
> > I did name these with the deferred "1" numbers, so that the "sig"
> > modifier has to do less work.  I think you have a more "generative"
> > viewpoint, but I like to be able to read simple "transformations" from
> > one pattern to another.
>
> Yes I wasn't sure about the simplification, no harm in being more explicit.
>
> >
> > > I also used "+" in the pattern naming ie
> > > Noise_IKsig_25519+Ed25519_AESGCM_SHA256 to make it clearer how to
> > > parse the names, and I think this works best with the composition
> > > rules although these need finalising. Using underscore the parsing is
> > > more implicit. The
> >
> > I didn't understand this paragraph, it got cut off?
>
> Lets leave this now, I think it makes sense with the other combination
> rules
> but lets review these first. It just groups the DH and DH like algorithms;
> in
> some future case where there is a pair of hash functions say it may be
> clearer.
>
> >
> > > Your additional patterns are then combinations. The combination rules
> > > are quite simple, for "i" patterns you use N.+.Nsig ie the sig
> > > modifier is applied to something that only has initiator keys, and the
> > > opposites.
> > >
> > > XKsigi is
> > > NK+XNsig:
> > >   <- s
> > >   ...
> > >   -> e, es
> > >   <- e, ee
> > >   -> s1, sig1
> >
> > For the cases with mixed DH and signature authentication, I would
> > definitely like to see your "pattern composition" approach fleshed
> > out.  Some questions I have about it:
> >
> >  * It's not obviously more readable, i.e. looking at above example:
> > XKsigi can be read and applied quite easily:  just take XK and replace
> > the initiator auth with a signature.  Viewing this as NK+XNsig takes
> > more thinking to "merge" 2 different patterns.
>
> Not obviously more readable, but I think the benefits of being more general
> and working for other combinations but lets see. I am interested in
> patterns
> like KK+XXsig for example.
>
> >  * If "pattern composition" automatically merges ephemeral, how would
> > we handle cases where we want to add or replace ephemerals, e.g.
> > hybrid forward secrecy?  If we're tackling a general composition
> > mechanism it probably needs to be able to combine DH, signatures, and
> > ephemeral or static KEMs, arbitrarily.
>
> Yes, I will need to make these cases clear.
>
> > > XXsigr is also valid, which is XN+NXsig, and XXsigi which is NX+XNsig
> > > - you didn't need to use the deferred patterns for the XX ones as
> > > XXsig is valid. K1K1sigi and K1K1sigr are also valid, and K1Xsigi and
> > > K1Xsigr, and I1K1sigi and I1K1sigr. So overall there are I think 8
> > > patterns that you miss that are valid, giving 31 patterns overall.
> >
> > I only included sigi/sigr if sig wasn't possible, but that was kind of
> > an arbitrary choice.  Also including sigi+sigr patterns would make
> > sense, to allow for different types of signature algorithms.
> >
> > > This is significantly more complex as a spec than my version with just
> > > 11 patterns plus composition rules to make up the other versions, so
> > > long as you agree the composition rules are simple (and I think they
> > > are otherwise useful). I will do a writeup of the composition rules
> > > this week.
> >
> > I'm not sure the composition rules are simple yet, but they're
> > definitely intriguing, particularly if they extend to handling other
> > cases.
> >
> > Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20181224/3e14c5e4/attachment.html>