[noise] Channel-bound keys

[Trevor Perrin]

It was bugging me that the "handshake hash" is being presented as a
single "channel binding value" for arbitrary protocols.  We can't know
what these protocols are doing so it's possible they will use the
handshake hash in sloppy ways that allows cross-protocol attacks.

So I added a notion of a "channel-binding value" based on some
"channel-binding label", cbv = HASH(h || label).  You can think of
this as an additional MixHash step which gives you a specialized
channel-binding value for different uses.

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

So now a resumption PSK would be handled something like this:
 - server sends 32-byte preliminary key pk, and corresponding session
ticket, to client
 - client and server calculate:
   - cbv = HASH(h || "PSK")
   - psk = HMAC-HASH(pk, cbv)
 - In the future, client sends the session ticket and uses NoisePSK with psk

?

Trevor


On Mon, Mar 13, 2017 at 1:14 AM, Trevor Perrin <trevp at trevp.net> wrote:
> I made a small start on revision 32 of the spec [1].
>
> I think the goals in [2], plus rekey, are still reasonable.  I added a
> Section on "Channel-bound keys" (#3).
>
> "To exchange a channel-bound key one party should send the other a
> preliminary 32-byte secret key pk. Both parties will then calculate
> the channel-bound key as the first 32 bytes of HMAC-HASH(pk, h)."
>
> This is intended to work for resumption PSKs, or for creating other
> non-Noise sessions from a single Noise session (e.g. QUIC/TLS).
>
> Channel-binding the transmitted keys with HMAC, instead of using them
> directly, is a new proposal.  In [3] I proposed using them directly,
> but that's probably too vulnerable to "Triple-Handshake"-type
> confusions, e.g.:
>  - a bad client is given a resumption PSK by the server
>  - the bad client somehow gives a good client the PSK
>  - the good client uses the PSK with the server, thus becoming
> associated with the bad client's previous traffic
>
> The downside of channel-binding is that a stateless server with
> TLS-like "session tickets" can't skip including the PSK in a session
> ticket and derive it instead, as proposed in [3].  That was an attempt
> at recouping the 32 transmitted bytes by making session tickets
> smaller.
>
> Otherwise, I like that this is fairly simple, doesn't require support
> from Noise libraries, and allows parties to exchange multiple keys
> whenever they want, protected with the latest re-keyed transport keys,
> as discussed in [3].
>
> Feedback welcome, as always!.
>
> Trevor
>
> [1] https://github.com/noiseprotocol/noise_spec/blob/rev32/noise.md
> [2] https://moderncrypto.org/mail-archive/noise/2017/000875.html
> [3] https://moderncrypto.org/mail-archive/noise/2017/000903.html