[noise] rev32b (Release Candidate)

[Trevor Perrin]

Tweaked the wording in 9.2 and 7.1 to be a little clearer (thanks to
Alex and Jake for suggestions).  Any other feedback?

Trevor

On Thu, May 11, 2017 at 6:27 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 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