[noise] Resumption PSKs

[Christopher Wood]

On Tue, May 29, 2018 at 3:09 AM Trevor Perrin <trevp at trevp.net> wrote:
>
> 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.

Would it not be cleaner to move this export functionality to a
different API? For example, one could specify an explicit Export() API
that functions precisely as you describe above, with the exception
that CipherState objects are not returned.

>
>
> >>  * 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
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise