[noise] Resumption PSKs

[Trevor Perrin]

On Tue, May 29, 2018 at 6:54 AM, str4d <str4d at i2pmail.org> wrote:
> 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?

Yes.


>>  * 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.

Yes, exactly.


>> 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 :)

I'm not sure I still agree!  There's an argument it's safer to always
mix h into additional keys, particularly with more resumption-like
uses, so this part of the design has open questions.

Another uncertainty:  We've had discussions about revamping Noise's
use of symmetric-crypto and hashing (like "NXOF", and Disco, and
"HASH/XOF refactoring").  Those ideas might result in refactoring our
approach to KDFs / PRFs (and HKDF / HMAC).

So one reason I haven't pushed this further was because I wanted to
get a better idea of how this would fit with any developments in how
we handle hashing.

Anyways, these things are solvable, particularly if someone is driving
us to make decisions, but I just wanted to flag some open design Qs.

Trevor