[noise] Revision 32 draft (march 30)

[Rhys Weatherley]

On Fri, Mar 31, 2017 at 11:40 AM, Trevor Perrin <trevp at trevp.net> wrote:

> Made a pass on the Noise spec, and got in almost everything I think we
> want in next revision.  No changes or incompatibilities, but some
> additions.
>
> Hopefully this doc can be frozen soon, as it's getting pretty stuffed.
> I'm thinking of starting an extensions doc to cover more complicated
> uses of Noise (hybrid forward secrecy, PSK and semiephemeral
> resumption, pattern transformations and combining them, etc.).
>
> https://github.com/noiseprotocol/noise_spec/blob/rev32/output/noise.pdf
> https://github.com/noiseprotocol/noise_spec/blob/rev32/noise.md
>
> Additions:
>
>  * Limit of 255 bytes to protocol names
>
>  * Rekey capability:
>    - Encryption with MAXNONCE is used to rekey by default, though we
> allow definition of a more specialized rekey for ciphers like
> AESGCM-SIV where we'd rather use the cipher key directly with AES,
> instead of going through the whole key-derivation / SIV process.
>    - Up to application if/when/how to use this.
>    - Would still like to analyze more, but this is probably good [1].
>

Rekey() looks good.  The only nitpick I have is with "returns a new 32-byte


>
>  * Strict vs non-strict DH functions:
>    - Allows a DH function to be defined with an error return (e.g.
> secp256k1 or other DH encodings that use compressed points and
> decompression).
>    - Could also be used to define a 25519strict (or whatever you'd
> name it) that checks for zero output, if one really wanted that.
>    - Would still like to think more about handling null public keys,
> right now this is a recommendation to define them, perhaps we leave it
> at that? [2].
>
>  * Channel-bindings UNCHANGED:
>    - I was thinking of doing HASH(h || label) or HMAC(h, label) to
> extract labelled channel-binding values.  But on further thought, if a
> higher-level protocol is using the channel-binding plus its own keys
> so sloppily that the output can be transferred between different
> contexts (i.e. cross-protocol attacks) that's the protocol's problem,
> not ours, so better to keep this simple.
>
>  * Pattern transformations and "noidh" removed.  I think things like
> this should go in an "extensions" doc discussing transformations and
> extensions like:
>    - "noidh" (identity-hiding)
>    - "hfs" (hybrid forward-secrecy)
>    - PSK and semi-ephemeral 0-RTT
>    - maybe extensions for altering when the PSK is applied (an idea of
> Jason's)
>    - extensions for adding/removing ss, or deferring DHs, etc.
>
>  * "Fallback patterns" instead of "dependent" patterns:
>    - The only case where initiator ephemerals are used as pre-messages
> is for fallback, so I overhauled the text to be more specific and I
> think clearer about this (see: Sections 8 and 9.1).
>    - Section 9 rewritten to be clearer (hopefully?) about all this.
>    - Roles don't change during fallback, so fallback patterns are
> written more nicely:
>
>     Noise_XX(s, rs):
>       -> e
>       <- e, ee, s, es
>       -> s, se
>
>     Noise_XXfallback(e, s, rs):
>       -> e
>       ...
>       <- e, ee, s, es
>       -> s, se
>
>  * Fixed the indistinguishable handshakes section, since it's not
> actually possible to use XX there.
>
> This is a slew of new text, so feedback appreciated!
>
> Trevor
>
> [1] https://moderncrypto.org/mail-archive/noise/2017/000944.html
> [2] [2] https://moderncrypto.org/mail-archive/noise/2017/000867.html
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170402/86722682/attachment.html>