[noise] Potential redesign?

[Trevor Perrin]

On Tue, Mar 17, 2015 at 10:15 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
>
> If we can come up with a clear, comprehensible taxonomy of the features
> each particular recipe/combination provides to users, then users can
> consult the checklist/table, and say something like "hm, i'm looking to
> do stream-based key establishment, and i care about 'Forward Secrecy'
> and about 'Server Identity Hiding', but not 'Client Authentication', so
> i should choose HandshakeNX".  (it looks like all the combos Trevor has
> listed have forward secrecy, but i suppose given the primitives
> available, we can come up with some that don't have forward secrecy
> too).

Yeah, I'm imagining libraries that provide the default combos, and
then have a more-dangerous interface for using your own descriptors.
Hopefully the default combos would suffice for most.

I think a feature-matrix possible.  Labelling the example messages:

sFS = sender forward-secrecy
rFS = recipient forward-secrecy
sAuth = sender authentication
rAuth = recipient authentication
sIDhide = sender ID is hidden

BoxSS                     sAuth* rAuth* (* = not KCI-resistant)
BoxNS           sFS              rAuth   -
BoxXS           sFS       sAuth* rAuth   sIDhide
BoxNE           sFS rFS          rAuth   -
BoxXE           sFS rFS   sAuth  rAuth   sIDhide

For handshakes, I only show messages up to the point that features
"stabilize", all subsequent messages in same direction have same
properties:

HandshakeNX->                            -
HandshakeNX<-   sFS rFS   sAuth          sIDhide* (* = anyone can solicit)
HandshakeNX->   sFS rFS          rAuth   -

HandshakeXX->
HandshakeXX<-   sFS rFS   sAuth          sIDhide*
HandshakeXX->   sFS rFS   sAuth  rAuth   sIDhide
HandshakeXX<-   sFS rFS   sAuth  rAuth   sIDhide*

HandshakeNS->   sFS              rAuth   -
HandshakeNS<-   sFS rFS   sAuth          sIDhide
HandshakeNS->   sFS rFS          rAuth   -

HandshakeXS->   sFS              rAuth   -
HandshakeXS<-   sFS rFS   sAuth          sIDhide
HandshakeXS->   sFS rFS   sAuth  rAuth   sIDhide
HandshakeXS<-   sFS rFS   sAuth  rAuth   sIDhide

HandshakeNE->   sFS rFS          rAuth   -
HandshakeNE<-   sFS rFS   sAuth          sIDhide

HandshakeXE->   sFS rFS   sAuth  rAuth   sIDhide
HandshakeXE<-   sFS rFS   sAuth  sAuth   sIDhide


> Maybe this kind of taxonomy is a pipedream?  or maybe the hope that
> protocol designers will think carefully enough to consult it effectively
> is a pipedream?

It sounds reasonable to me that some protocol designers could think
clearly about round-trips, forward-secrecy, identity-hiding,
pre-knowledge of keys, etc, and then map that to one of several solid
protocols.

Trevor