[noise] Channel-bound keys
trevp at trevp.net
Mon Mar 13 14:44:04 PDT 2017
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.
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
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 .
> I think the goals in , 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  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 . That was an attempt
> at recouping the 32 transmitted bytes by making session tickets
> 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 .
> Feedback welcome, as always!.
>  https://github.com/noiseprotocol/noise_spec/blob/rev32/noise.md
>  https://moderncrypto.org/mail-archive/noise/2017/000875.html
>  https://moderncrypto.org/mail-archive/noise/2017/000903.html
More information about the Noise