[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