Re: [TLS] Proposal: Simplified Key Schedule

[Hugo Krawczyk <[e-mail]>]

I agree that once you remove the requirement to derive a key from g^xy (=ES)
for protecting a static DH key then the KDF scheme can be simplified as
shown
(or even further - see below).

Note that this is (almost) exactly the original KDF scheme of OPTLS as I
presented in Dallas
https://www.ietf.org/proceedings/92/slides/slides-92-tls-4.pdf
See slide 4 for the KDF scheme and slide 3 for the key names; it can be
confusing as what I call ES (for Ephemeral-Static, or g^xs) is now called
SS and what I call EE (for Ephemeral-Ephemeral, or g^xy) is now called ES.
Also note that I simplified the presentation in these slides by referring to
both HKDF-extract and HKDF-expand by PRF.

Anyway, from here you can see that the last HKDF in your scheme (with 0
salt)
is not needed. You can derive the RMS, EMS keys directly from the second
HKDF
(as siblings of 1-RTT Traffic Keys). Am I missing something?
If the third HKDF is only to accommodate a DH-cert variant then I don't
think
it's worth it (if in that variant we will need a special key derivation
step
anyway then no need to plan for it now).
If this third HKDF is needed for other reasons let me know.

What I do miss in this scheme is the derivation of the Finished keys. I hope
you do not intend to use the application key for this!

I also want to stress, for the record, that this simplification has nothing
to
do with using the application keys for handshake protection. That
"optimization"
is orthogonal to this KDF simplification and hopefully will be reverted (*).

(*) You may say I'm a dreamer, But I may not be the only one :-)

Hugo

PS: I have a disagreement with you in terms of the protocol now being
"signature based". Yes there are signatures in the protocol but not all
modes
use them and they are not always needed. In my eyes the logic of the
protocol
is best seen as DH-based with authentication occurring through the server
Finished MAC (with a key derived from SS which can take the values of g^xs,
g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK which
do
not build on signatures. This is how the protocol was built originally and
that structure remains in spite of the added signatures.


On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla <[e-mail]> wrote:

> Hi folks,
>
> TL;DR.
> Let's simplify the key schedule.
>
>
> DETAILS
> This is the second in a series of proposed simplifications to TLS 1.3
> based on implementation experience and analysis once the protocol
> starts to harden.  The following suggestion comes out of conversations
> with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud,
> Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and
> others.
>
> The current key schedule is elegant but it is actually more than we
> need in that it allows SS to be known either before or after ES. If we
> assume (as is always true in the current TLS 1.3 modes) that SS is
> known before or at the same time as ES, then we can design a simpler
> scheme which looks more like a ladder. Something like:
>
>                         0
>                         |
>                  SS -> HKDF [ClientHello + Context]
>                         |  \
>                         |   \
>                         v    v
>                         X1   0-RTT Traffic Keys *
>                         |
>                         |
>                         v
>                  ES -> HKDF [ClientHello, ServerHello]
>                         |  \
>                         |   \
>                         v    v
>                         X2    1-RTT Traffic Keys *
>                         |
>                         |
>                         v
>                   0 -> HKDF [ClientHello...ClientFinished]
>                         |
>                         |
>                         v
>                         RMS, EMS
>
> As should be apparent, this key schedule is well-suited to the
> simplified key change schedule in my previous message.
>
> Note 1: It might be attractive to not even bother with the first stage
> if you aren't doing 0-RTT. It's not necessary then.  However, this is
> just an optimization. Also, if you don't want to extract an RMS or an
> EMS you can skip the last stage (this is compatible).
>
> Note 2: The IKM for the final HKDF is 0, but in principle we could use
> it to add some sort of new keying material, for instance g^xs if we
> were using static DH certificates (see below).
>
>
> In line with Hugo's message earlier today, the major argument against
> this design is that it is more oriented towards a signature-based
> system, which TLS 1.3 is today, than towards a DH certificate-based
> system. To elaborate on this a bit, in a DH certificate-based system,
> the server authenticates by proving knowledge of g^xs (and hence
> s). In the current TLS 1.3 design you can do this trivially by
> replacing the signature in the server CertificateVerify with a MAC
> over the transcript (using g^xs as the key) [again, analysis needed.]
> This is straightforward and doesn't require rearchitecting the
> protocol really at all. However, this (as with the current
> signature-based mode) does not provide confidentiality of the
> connection if y is later revealed.
>
> As Hugo has noted several times, if you mix both g^xy and g^xs into
> the traffic keys, then you are protected if either y or s is leaked,
> which gives you somewhat stronger security properties with a DH
> cetificate The current key schedule accommodates that by allowing for
> SS to come before *or* after ES, but the simplified schedule does not
> quite so easily.
>
> With that said, TLS 1.3 doesn’t support *any* pure static DH design
> now and will do so even less well if we remove the key change as
> discussed above. There are at least three ways forward to incorporate
> them in future:
>
> - Just do as I suggest above.
> - Define a new DH cipher suite that adds an additional key change.
>   This would allow us only to have the key change complexity in
>   that mode.
> - Replace the 0 in the above schedule with g^xs and then define that
>   the key for KeyUpdate is actually coming out of the final HKDF.
>
> Any of those seem like they wouldn’t be too hard to do, if and when
> we start having a lot of demand for DH certificates.
>
> Please discuss.
>
> -Ekr
>
> * Note that as I indicated in my previous message, it is possible to
> generate multiple sets of keys at the same stage, if that is necessary
> to handle the analysis concerns.
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>