[noise] rev32b (Release Candidate)

[Trevor Perrin]

Hi folks,

The "rev32b" branch has been updated with the new PSK design discussed
in the "Reworking PSK usage" thread.

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

I'd like to publish this on Tues, so please read and send feedback.


This revision will break compatibility with previous PSK patterns.
However, this is based on extensive feedback and ideas from WireGuard,
who plans to use the IKpsk2 pattern for their next version.  I'm not
aware of other PSK users, and haven't heard objections since
announcing this.

In retrospect, the old PSK design was a hack:  It mixed the PSK at the
beginning, but for patterns where identities are revealed during the
handshake, this is unlikely to make sense.  Also, the old design used
a special naming scheme and didn't make use of tokens.

The new design provides PSK flexibility with a "psk" token, and uses a
naming scheme that fits with the "modifier" syntax we currently use
for "fallback", and have discussed using for signatures ("sig"),
post-quantum ("hfs"), and other pattern transformations ("noidh",
others).

This revision improves some other things:

 * A new CipherState.Rekey() function is added, so applications can
update their cipher keys via an efficient one-way function.  We've
seen applications want this and roll-their-own (Lightning), so it will
be good to have a documented method in the spec.  The approach we've
found is simple and efficient.

 * DH requirements have been clarified, including the security
requirement ("Gap-DH"), and allowance for implementation variability
when X25519 or X448 produces the all-zeros output, or other elliptic
curves (e.g. secp256k1) produce errors on a failed point decoding.  (I
think this variability is annoying for X25519/X448; you can read my
opinion on the curves list, but the reality is people are implementing
X25519 in different ways, so we'll have to tolerate that).

 * Removed the "null public keys" feature, because this doesn't work
well with some X25519 implementations, and it's not obvious how to
port this to different elliptic curves (e.g. secp256k1, FourQ).  We
still discuss "dummy public keys", but those can have arbitrary
values.

 * Discussion of fallback patterns and pipes was completely rewritten
to be clearer, including treating the notation for "fallback patterns"
specially so that the initiator and responder don't change roles,
making the XX and XXfallback relationship much more readable.

 * Removed "noidh" patterns, we have more important examples of
modifiers ("fallback", "psk0" etc), so we'll figure out how to
document "noidh" and other transformations later.

 * Previously, a party was allowed to send multiple ephemerals, which
would overwrite the previous ephemeral; but only a single static.
This is changed so parties can only send a single ephemeral, to make
the rules simple and consistent.

We had conjectured that allowing multiple ephemerals would give us
flexibility for "semi-ephemeral" resumption in the future, where an
initial, cached, pre-message "semi-ephemeral" was replaced during the
handshake.  However, pre-message ephemerals have ended up being more
important for fallback patterns, so I no longer think it makes sense
to also use them as "semi-ephemerals" - instead, we should define a
different token for such a different use case, when we get to that.

 * Relaxed the validity requirement that ephemerals have to come at
the beginning of patterns.  This was partly due to the previous PSK
design, but for the new PSK design it seems more readable to allow a
"psk" token to start the pattern, so we provide a more flexible
validity rule for PSKs.

 * Numerous small clarifications, e.g. about error-handling in Section
5, nonce limits in 5.1, explanation of the "modifier" syntax, 255-byte
limit on names, a mistake in "handshake indistinguishability" was
corrected, "dummy PSKs" discussed, sub-sections to organize the
Rationales, extensive rationale for HMAC/HKDF, etc.

A note on the future:

This spec is long (maybe too long) and complicated (maybe too
complicated).  We want to keep adding features, but it's not clear the
best way to do so (keep adding to this spec? reorganize this spec,
e.g. move patterns/tables to an appendix? create another spec?  Have
"core" and "extensions" documents, based on splitting this spec
somehow?)

So there's discussions we'll need to have later about restructuring
the document(s), clarifying processes for new features, maybe even
being more formal about maturity and conformance levels or something.

On the other hand, any changes like this add complexity, affect a lot
of stakeholders in different ways, and might be terrible ideas.  So
let's plan on having some post-32 discussions about document structure
and process.  However, for the moment let's focus on getting this
revision out, since customers like WireGuard want to build on it, and
I believe it's a significant improvement.

Trevor