[noise] Revision 20

[Jason A. Donenfeld]

Hi Trevor,

Awesome! This is, by far, the best rendition of the spec so far. Very
neat and easy to follow. I think this will help noise gain traction
once it's finalized. I'll have a look in depth at the security
properties tomorrow and check them. First, some preliminary rewordings
and questions, none of which are overly important:


> The second message's payload can also be used to deliver
> certificates for the responder's static public key.

That's a neat usage of it. How do you envision this being used
in a larger scheme exactly?


> InitializeKey(empty)

You might want to write this as InitializeKey([empty]) or some
other way of separating this from variables. You make it more clear
later on where you define "zerolen". Maybe something like that.


> Initialize(handshake_patern, ...

The list below this doesn't indent properly on all markdown
implementations. See <http://git.zx2c4.com/noise/about/> for an
example. I sent a patch at some point for how to fix this.


> The pre-messages represent an exchange of public keys that was
> somehow performed prior to the handshake, so these public keys
> must be inputs to Initialize() for the "recipient" of the pre-message.

The language here is confusing. Perhaps reword this to:
" The pre-messages represent an exchange of public keys that was
" somehow performed prior to the handshake, which is why these public
" are passed to MixHash() during step X of Initialize().
Though, you already say pretty much this a few paragraphs later, so
maybe just nix this sentence all together.


> Parties can only send static public keys they possess, or perform
> DH between keys they possess.

By possess, do you mean that "parties can only send static public keys
if they possess the corresponding private key"? The way it's written now
makes it seem like parties can only send public keys if they have a public
key to send, which is something of a tautology and I don't think is what
you meant to write.


> Parties must send a new ephemeral public key at the start of the first
> message they send (i.e. the first token of the first message pattern in
> each direction must be "e").

To make it more clear that each party needs to have "e" at the beginning:
" Each party must send a new ephemeral public key at the start of the first
" message sent by each party. (i.e. the first token of the first message
" pattern in each direction must be "e").


> could result in subtle but catastrophic security flaws.

It might be worthwhile to add on a paragraph to this section something along
the lines of:
" The above guidelines have motivated the patterns written in sections 7.2 and
" 7.3. It is recommended to use these patterns rather than creating new ones,
" unless absolutely neccessary.
The reason for this is that pretty much everything up to this point is rather
easy to implement, and I doubt there will be too many pitfalls. But as soon
as people start feeling bold enough to invent their own patterns, the warnings
of section 7.1 will be swiftly forgotten and disasters will occur. So, a
"don't try this at home, kids" message like the above might be wise.


> Following a one-way handshake the sender can send a stream of transport
> messages, encrypting them using the first CipherState returned by Split().

The payload section of the handshake message of any of the one-way patterns
will have the same security guarantees as those of the transport messages,
> right?


>   _R = static key for responder transmitted to initiator, but only
>        after the initiator has revealed their identity

This is a very nice addition. Thanks for that.


> After receiving a transport message from the initiator, the responder
> becomes assured of "strong" forward secrecy.

It's nice to read it put clearly like this. I had asked about this very
thing prior on the mailing list. I believe this is similar to the
distinction between KEA+ and KEA+C. (With WireGuard I enforce the "strong"
forward secrecy.)


> 7.4. Payload security properties

AMAZING! Thank you for writing this. It's exactly what I've been hoping to
read for a while.


> These patterns might benefit from signatures, which are not yet
> included in Noise.

>From here and other comments (and early Noise and TripleDH papers you wrote),
it appears you're already beginning to have some ideas about this. Do you
envision breaking changes - a Noise v2?


> This technique is simple, since it allows use of a single handshake
> pattern. It also doesn't reveal which option was chosen from the
> message size.

That's clever. Neat.


Jason