[noise] Generalizing for different handshakes? (was: Use cases which don't fit Noise Pipes)

[Trevor Perrin]

On Fri, Feb 13, 2015 at 6:04 PM, Kenton Varda <kenton at sandstorm.io> wrote:
>>
>> I'd like to optimize the connection opening between Bob and Carol such
>> that:
>> - When Alice decides to introduce Bob to Carol, she can immediately send
>> the introduction message to each without any non-local preparation.
>> - As soon as Bob receives the introduction message from Alice, he can
>> start sending messages to Carol, without any handshake. Similarly, Carol can
>> immediately begin sending messages to Bob.


Thanks Kenton,

This makes sense and is a direction people are exploring.

Basically you want a "0-RT" handshake assuming the initiator gets
assistance from an "introducer".  QUIC, MinimaLT, and I think TLS 1.3
are looking into that (though maybe focusing more on resumption than
introduction).  This could be done in different ways - for example,
the introducer could provide the initiator with the responder's
long-term public key, or also an ephemeral-ish public key.

Currently Noise isn't designed for this - there's only a 1-RT
handshake which provides strong identity-hiding for the initiator, and
"post-specified peers" (meaning the parties receive each other's
certificates and public keys during the handshake, without needing -
or benefiting from - prior knowledge of them).  The rationale was to
emphasize security (identity-hiding) and generality (post-specified
peers instead of pre-specified; mutual auth instead of one-sided).

Also, Noise pipes are built out of a "box" primitive that uses 2 DH
keys from the sender and 1 from the receiver.  These boxes nicely
compose into a 1-RT handshake, but the resulting handshake doesn't
have flexibility to reorder or remove elements for optimization.

Mike demonstrated how this sort of handshake can be viewed as
accumulating DH shared secrets into some evolving secret key ("chain
key", or "chaining variable") that encrypts subsequent data [1,2].
Adapting his notation:
 A, B : Alice and Bob's long-term public keys
 A', B' : Alice and Bob's ephemeral public keys
 [XY] : Indicates an action rather than message data - the DH
shared-secret between keys X and Y is mixed into the evolving secret

So the NaCl box is:

Alice -> Bob: [AB], data

Meaning the DH secret between public keys A and B is used to encrypt
data.  The Noise box is:

Alice -> Bob: A', [A'B], A, [AB], data

Meaning Alice sends her ephemeral public key, uses the DH with Bob's
key to hide her identity (her long-term public key), and then uses
both DHs to encrypt the data.

The Noise pipe handshake is:

Alice -> Bob: A'
Alice <- Bob: B', [A'B'], B, [A'B], data   # box
Alice -> Bob: A', [A'B'], A, [AB'], data   # box

(Note that Bob's "data" is sent without doing authentication or key
confirmation with Alice, or even knowing her identity, so there are
important difference in the security properties for "data" depending
on when/how data it's sent during the handshake).

The symmetry of the 2nd and 3rd messages and reuse of the box pattern
is nice.  But an alternative design might de-emphasize this pattern
and allow chain keys and DH to be combined more flexibly.

For example, below are several handshakes that fit the "chain key"
pattern but show optimizations based on:
 - pre/post-specified peer (and which keys are pre-specified: only the
long-term or also an ephemeral "prekey")
 - mutual auth or server auth
 - identity-hiding or not

# (1) Post-specified peer, mutual auth, identity-hiding (~Noise)
Alice -> Bob: A'
Alice <- Bob: B', [A'B'], B, [A'B], data
Alice -> Bob: A, [AB'], data

# (2) Post-specified peer, mutual auth, no identity hiding
Alice -> Bob: A, A'
Alice <- Bob: B', [A'B'], [AB'], B, [A'B], data

# (3) Post-specified peer, server auth (~Ntor)
Alice -> Bob: A'
Alice <- Bob: B', [A'B'], B, [A'B], data

# (4) Pre-specified peer (long-term only), mutual auth
Alice -> Bob: A', [A'B], A, [AB], data
Alice <- Bob: B', [A'B'], [A'B], data

# (5) Pre-specified peer (long-term only), server auth
Alice -> Bob: A', [A'B], data
Alice <- Bob: B', [A'B'], data

# (6) Pre-specified peer (long-term and ephemeral), mutual auth (~TextSecure)
Alice -> Bob: A', [A'B'], [A'B], A, [AB'], data

# (7) Pre-specified peer (long-term and ephemeral), server auth
Alice -> Bob: A', [A'B'], [A'B], data


I'd like to think more about this, but it may be worthwhile to have
Noise (or similar) be general enough to instantiate all of these, and
other things as well (e.g. Axolotl).


Trevor

[1] https://moderncrypto.org/mail-archive/noise/2015/000098.html
[2] https://moderncrypto.org/mail-archive/noise/2015/000108.html