[noise] Channel-bound keys

Trevor Perrin trevp at trevp.net
Mon Mar 13 01:14:19 PDT 2017


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


More information about the Noise mailing list