[noise] Resumption PSKs

[str4d]

On 02/27/2018 05:21 AM, Trevor Perrin wrote:
> Hi all,
> 
> We had threads last year on "resumption PSKs", i.e. PSKs derived from
> a parent session that are used for a 0-RTT child handshake [1,2].
> 
> Let's finish off the design so we can write an extension spec.
> 
> 
> Proposal:
> 
>  * Split() is modified to take a list of N "labels" (label = byte-sequence).
> 
>  * Split() is modified to return a list of N "key chains".  Each key
> chain has a chaining key ck and can output a sequence of 32-byte keys
> k by calculating ck,k = HKDF-Expand(ck).

To be clear, this is in addition to also returning the two CipherState
objects, which would be derived in the usual backwards-compatible way?

> 
>  * Each key chain is initialized by taking an additional output K from
> the HKDF in Split(), then setting ck = HMAC(K, label).  After all the
> key chains are initialized, K is deleted.

The wording here is not ambiguous per-se, but is a little misleading. I
assume the intent is that we take only a single additional output K from
the HKDF in Split(), rather than one additional output K per key chain.

> 
>  * To get resumption PSKs, you use a label "psk" and then get as many
> resumption PSKs as you need from the resulting key chain.
> 
>  * If you want an identifier for each PSK so that the client can
> specify them to the server, you use an additional label "pskid", and
> the "keys" from this chain serve as identifiers for the keys from the
> "psk" chain.
> 
>  * For resumption, the handshake hash "h" for the parent session must
> be stored and used as prologue for the child session.
> 
>  * Alternatively, to avoid storing an extra 32 bytes, a "compressed
> resumption" can be used where a compressed "resumption value" of
> HASHLEN bytes r = HMAC(PSK, h) is calculated, and then "decompressed"
> later as PSK',h' = HMAC-Expand(r, "decompress").  PSK' is then used as
> the child's PSK, and h' is used in the child's prologue.
> 
> 
> Notes:
> 
>  * This mechanism for deriving additional keys could be used for other
> purposes (e.g. if you want keys for additional streams between client
> and server).
> 
>  * This mechanism has the property that after outputing a resumption
> PSK, this PSK is independent from any of the keys held by the parent
> session (the PSK can't derive them, and they can't derive it).  This
> gives parent and child sessions independent forward-secrecy.  This
> property is not achieved in TLS 1.3.
> 
>  * The PSKs derived here are just 32-byte symmetric keys with the same
> security as the parent's session keys.  They are *NOT*
> collision-resistant hashes that incorporate the parent's "h".  Instead
> we require the parent's handshake hash to be specified explicitly in
> the prologue, either as a separate value or a compressed/decompressed
> value.
> 
> 
> This last point is a major design decision.  An alternative design
> (more like TLS 1.3) would make all additional keys a HASHLEN-size hash
> of K and h, and would make all PSKs a HASHLEN-sized input.
> 
> I think we should not do this, for a few reasons:
> 
>  * If the additional keys k are being used immediately (e.g. for
> additional streams between client and server), we don't need the extra
> cost and complexity of mixing in the transcript hash and expanding
> this to HASHLEN bytes.

As someone who wants to use a key chain immediately for another purpose,
I agree with this :)

> 
>  * If child sessions are defined in terms of a HASHLEN-sized PSK value
> that may (or may not) incorporate a parent's handshake hash, then the
> parent's hash becomes an invisible but security-critical input.  It
> would be easy to forget about it, and use the child handshake with a
> PSK from some other source.  Thus, I think it's better to make the
> parent handshake hash an *explicit* parameter.

I agree that explicit is better than implicit.

> 
>  * Relying on "identities" hashed into "session keys" in the context
> of DH-authenticated protocols is something we've avoided due to
> Microsoft's KEA+ / "Extended authentication key exchange".  The
> "compression" mechanism is different enough that I think this is not a
> concern.
> 
> Thoughts?

Overall I like this proposal. I don't have comments on its applicability
specifically to resumption PSKs.

I'm going to try implementing this in snow now :)

str4d

> 
> Trevor
> 
> [1] https://moderncrypto.org/mail-archive/noise/2017/001212.html
> [2] https://moderncrypto.org/mail-archive/noise/2017/001402.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: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180529/69e40b74/attachment.sig>