[noise] Revision 32 draft (april 7)

[Trevor Perrin]

More spec cleanup:

https://github.com/noiseprotocol/noise_spec/blob/rev32/output/noise.pdf

Take a look, I'm still hoping we can publish this soon and then leave
it alone for a long time, while we shift attention to things like
NoiseSocket, and an Extensions document.


Most of it's minor clarifications, but I'm trying a couple substantive changes:

 (1) Removed strict/nonstrict DH distinction.  Instead, this draft
allows DH implementations to handle "invalid" public keys by either
returning an error or a constant value.  Specific DH functions can
apply tighter rules if they want:

"""
The `public_key` either encodes some value in a large prime-order group (which
may have multiple equivalent encodings), or is an invalid value.
Implementations must handle invalid public keys either by returning some output
which is purely a function of the public key and does not depend on the private
key, or by signaling an error to the caller.  The DH function may define more
specific rules for handling invalid values.
[...]
 **`DH(keypair, public_key)`**: Executes the Curve25519 DH function (aka
   "X25519" in [@rfc7748]).  Invalid public key values will produce an output
   of all zeros.

     Alternatively, implementations are allowed to detect inputs that would
     produce an all-zeros output and signal an error instead.  This behavior is
     discouraged because it adds complexity and implementation variance, and
     does not improve security.  This behavior is allowed because it might
     match the behavior of some software.
"""

I'm annoyed we might have to allow implementation variance like this
(since it complicates testing, and anonymity).  25519 DH as was
defined by DJB, and widely deployed, had no return value.

But the IETF is popularizing the idea that 25519 DH benefits from
raising an error for the all-zeros output.  Noise doesn't require
this, nor does any well-designed protocol (NaCl, Signal, TLS 1.3,
etc).

Howver, the 25519 ecosystem is going to have lots of software with and
without this check, for the foreseeable future.  Allowing both
implementations is probably just a concession to reality.


 (2) Removed "null public keys".  We still discuss "dummy public
keys", so you can use XX without client auth, but we no longer take
advantage of setting the public key to zeros to signal this (and skip
the DH computation).

This was tied to all-zero outputs from 25519 and 448, so if we're
going to allow errors in that case this makes less sense.  It also
makes less sense for other curves (e.g. secp256k1).

No-one has wanted to use this, so far.  And it's not required for
"dummy public keys", since we can just let the application payloads
say whether a static key is a dummy or not.  So getting rid of this
simplifies things without losing much.


Other changes:
 * Subtitled "Core Specification"
 * Clarified handling of errors in 5
 * Clarified handling of nonces in 5.1
 * Expanded out the DH cases in ReadMessage/WriteMessage (instead of "xy")
 * Discuss AESGCM data volumes as another use for rekey
 * Reorganized Rationales section, added subsections
 * Added rationales (including the perennial HMAC vs keyed BLAKE2 discussion)


Trevor