[noise] Revision 20

[Trevor Perrin]

Thanks for the feedback, made some editorial changes (rev 21).

https://github.com/trevp/noise/blob/master/noise.md

Comments -


On Wed, Feb 3, 2016 at 4:56 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
>> 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?

The payload would just have a signature over the static public key
from some offline or 3rd-party key, and perhaps a chain of
certificates.


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

In defining k I added: "Empty is a special value which indicates k has
not yet been initialized."


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

I'll have to do a bunch of cosmetic stuff to improve formatting, add
cross-reference links etc later, probable leave it be for the moment.


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

Hmm, I'll think about this wording some more.


>> 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"?

Clarified to: "Parties can only send a static public key if they were
initialized with a static key pair, and can only perform DH between
private keys and public keys they possess."


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

Not sure if that's any clearer.


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

There's some Security Considerations on some of that, but I added:

"Users are recommended to only use the handshake patterns listed
below, or other patterns that have been vetted by experts to satisfy
the above checks."


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

Right, that's mentioned in 7.4.


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

Certainly not breaking changes.  Signatures are a plausible eventual
addition in a v2 or something, but they'd just be an extra token or
token(s).

Not eager to tackle that soon though, I think we've got more than
enough here to experiment with and get good use from.


Trevor