[noise] Hashing additional context into handshake

[dawuud]

Hi Trevor,

I just wanted to say that I think this is a very important.
Hopefully projects currently using IK and the like would switch
once these alternative 0-RTT encryption patterns are specified.

Besides low latency there seems to be yet another reason to using
these patterns and that is: a very weak form of traffic analysis
resistace. At least for the duration of the handshake these 0-RTT
handshakes don't leak as much timing information which could be used to
identity the type of service.

Another approach which I find more appealing would be to design a
separate protocol for the purpose of resisting traffic analysis and
use that to encapsulate the service's inner crypto protocol. This is
essentially what Tor Project does when they use the obfs4 plugable
transport to encapsulate the Tor protocol. It's certainly more heavy
weight but affords greater protocol agility.

Sincerely,
David


On Sat, Jun 30, 2018 at 07:17:23PM +0000, Trevor Perrin wrote:
> Noise currently documents how to do 0-RTT encryption based on the
> responder's long-lived static key.
> 
> We've been slowly working out 2 additional ways to do it:
> 
>  (1) PSK-based resumption:  Use an "Additional Symmetric Key"
> mechanism to derive a resumption PSK from an initial session, and then
> use that PSK in a later handshake.
> 
>  (2) Short-lived statics:  The server changes its static key
> frequently, and signs the static key with an Offline Signing Key.  A
> client can lookup the current short-lived static key + OSK public key
> + OSK signature from some directory, or can fetch these values from
> the server itself by doing a handshake like NX or XX.  Then the client
> can use the short-lived static with a 0-RTT encrypted handshake like
> NK, XK, or IK.
> 
> 
> In both (1) and (2) the need might arise to bind some additional
> "context" into the handshake:
> 
>  (1) We might want the resumed PSK handshake bound to a
> collision-resistant hash of the original handshake transcript, to
> ensure that the client and server have the same view of the original
> handshake.  The Additional Symmetric Key mechanism hashes h into each
> output key (ASK), but h might be 512 bits, and ASKs and PSKs are only
> 256 bits.
> 
> To preserve the full 512 bits for collision-resistance when using
> 512-bit hashes, we could use the ASK mechanism to derive both a PSK
> and a PSK "addendum" value [1].  The addendum would be a second
> 256-bit value that should be hashed into the transcript of the resumed
> handshake.  It can be also be used an an identifier for the PSK, e.g.
> the client could send the first 128 bits of the addendum to tell the
> server which stored PSK to use.
> 
> It's not clear how the addendum would be hashed into the the resumed
> handshake, but [1] proposes including it in the prologue.
> 
>  (2) When encrypting to a short-lived static public key signed by an
> Offline Signing Key, it's important to somehow bind the handshake to
> the OSK public key.  Otherwise you might contact some directory and
> fetch an OSK public key + signature that were provided by a malicious
> party who is trying to "take credit" for the server's communication -
> this is a classic "Unknown Key Share" attack.
> 
> It's not clear how the OSK public key would be hashed into the
> handshake, however.  In the past we've talked about using the prologue
> [2].
> 
> 
> So in both (1) and (2) there's a need for a mechanism to bind some
> additional data (a PSK addendum or OSK public key) into the handshake.
> We could try to stuff all these into the prologue, but we'd have to
> define more structure (protobufs?) and APIs to fit all these different
> things into the prologue, and it's messy to be adding all this outside
> our existing naming / patterns mechanisms.
> 
> An alternative might be:
> 
>  * Define a new "h" token which is processed simply as
> MixHash(some_data).  (This idea was already discussed in the thread
> about "Authentication of handshake data between messages").
> 
>  * Define modifiers to insert this token for cases (1) and (2):
> 
>    - For (1), a "pska?" modifier could be the same as "psk?", but also
> inserts the "h" token prior to the "psk", and "h" is used to
> MixHash(psk_addendum).  So for example, NNpska0 would become:
> 
> 
> NNpska0:
>   -> h, psk, e
>   <- e, ee
> 
> 
>    - For (2), an "osk" modifier would insert the "h" token prior to
> the first use of the server's static in a DH.  "h" would be used to
> MixHash(OSK_public_key).  So for example, NK would become:
> 
> NKosk:
>   <- s
>   ...
>   -> e, h, es
>   <- e, ee
> 
> 
> Thoughts?
> 
> Trevor
> 
> [1] https://moderncrypto.org/mail-archive/noise/2018/001636.html
> [2] https://moderncrypto.org/mail-archive/noise/2017/001215.html
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180703/66de0586/attachment.sig>