Re: [TLS] Key Schedule (PRs #453, #454).

[Eric Rescorla]

Merged.

On Thu, May 19, 2016 at 10:41 AM, Eric Rescorla  wrote:

> PR: https://github.com/tlswg/tls13-spec/pull/454
>
> I have uploaded a PR [technically two PRs, but one builds on the
> other, so easier to just read the composition] which resolves two out
> of the three significant remaining crypto issues (the remaining one is
> the long-running discussion of post-handshake keys). The following
> message lays out the changes, which are:
>
> - Adopt a more linear key schedule
> - Add a context identifier for resumption
>
>
> KEY SCHEDULE
> We had a lot of comments that the existing key schedule was too hard
> to understand and implement and could be simplified under the
> assumption that keys were available in a specific order (PSK then DH
> ZZ). I've been working together with Karthik, Hugo, Antoine, and
> others to produce something cleaner. (Note: I believe they consider
> this acceptable, but that doesn't mean they wouldn't have designed
> every piece exactly as I have.)
>
>
> The overall key schedule looks like this:
>
>  0
>  |
>  v
>PSK ->  HKDF-Extract
>  |
>  v
>Early Secret  --> Derive-Secret(., "early traffic secret",
>  | ClientHello)
>  | = early_traffic_secret
>  v
> (EC)DHE -> HKDF-Extract
>  |
>  v
>   Handshake
>Secret -> Derive-Secret(., "handshake traffic secret",
>  | ClientHello + ServerHello)
>  | = handshake_traffic_secret
>  v
>   0 -> HKDF-Extract
>  |
>  v
> Master Secret
>  |
>  +-> Derive-Secret(., "application traffic secret",
>  | ClientHello...Server
> Finished)
>  | = traffic_secret_0
>  |
>  +-> Derive-Secret(., "exporter master secret",
>  | ClientHello...Client Finished)
>  | = exporter_secret
>  |
>  +-> Derive-Secret(., "resumption master secret",
>ClientHello...Client Finished)
>= resumption_secret
>
>   Derive-Secret(Secret, Label, Messages) =
>HKDF-Expand-Label(Secret, Label,
>  Hash(Messages) + resumption_context, L))
>
>
> Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons
> indicated below. If a key is missing you just use 0s.
>
> The general pattern here is that the secrets shown down the left side
> of the diagram are just raw entropy without context, whereas the
> secrets down the right side include handshake context and therefore
> can be used to derive working keys without additional context.  All
> the working keys (both encryption keys and finished keys) are
> generated using HKDF-Expand-Label off of the traffic secrets.
>
> This design is motivated by the following principles:
>
> - Separate out adding entropy from adding context.
> - Incorporate the transcript once and then derive from there.
> - Have a narrow, consistent interface for generating the leaf keys
>   so they can just start with a base key.
> - Derive from keys as soon as practical so that you can destroy them
>   (thus the final call to Add-Secret, which isolates the
>   Finished keys from the MS).
>
> An additional nice point about this design is that it easily
> accomodates additional keys. For instance, if we had some post-quantum
> key exchange method, we could easily add its key in the final
> Add-Secret or add an extra Add-Secret stage before HS. Similarly, if
> we had a long-term DH key as in OPTLSv1, it could replace the 0 in the
> final Add-Secret.
>
> One thing I want to call out explicitly is that we are using
> HKDF-Expand-Label with the output of HKDF-Expand-Label. This is
> cryptographically fine, but means that you need an implementation of
> the individual HKDF Expand/Extract primitives. As far as I can tell,
> this isn't a hardship for anyone, but please speak up if it is. The
> advantage of this is that you remove unnecessary crypto operations.
>
>
> CONTEXT IDENTIFIER
> PR: https://github.com/tlswg/tls13-spec/pull/454
>
> Hugo and Karthik both independently suggested that it would be nice to
> have some identity/context bound into the PSK handshake. The second PR
> accomodates that by deriving two values from the RMS:
>
>resumption_psk = HKDF-Expand-Label(resumption_secret,
>   "resumption psk", "", L)
>
>resumption_context = HKDF-Expand-Label(resumption_secret,
>

Re: [TLS] Key Schedule (PRs #453, #454).

[Martin Thomson]

I also agree, FWIW, but expected that this would be addressed by any
changes to 0-RTT and PSK in general.

On 20 May 2016 at 09:05, Eric Rescorla  wrote:
> Thanks for the clarification. Yes, I believe that is true.
>
> -Ekr
>
>
> On Thu, May 19, 2016 at 11:34 PM, Ilari Liusvaara 
> wrote:
>>
>> On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote:
>> > On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara
>> > 
>> > wrote:
>> > >
>> > > In very quick'n'dirty security analysis the other thing I noticed was
>> > > that if server handshake needs something to be nonce w.r.t. "SS",
>> > > (e.g.
>> > > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts
>> > > anyway, even with just "SS" being PSK.
>> >
>> > Sorry, I think you lost me there. Can you rephrase?
>>
>> Basically, I think that without contexts, PSK+ServerCert modes like MT
>> proposed (for 0-RTT with server certificate auth) run into cryptographic
>> issues.
>>
>>
>> -Ilari
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Schedule (PRs #453, #454).

[Ilari Liusvaara]

On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote:
> On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara 
> wrote:
> >
> > In very quick'n'dirty security analysis the other thing I noticed was
> > that if server handshake needs something to be nonce w.r.t. "SS", (e.g.
> > happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts
> > anyway, even with just "SS" being PSK.
>
> Sorry, I think you lost me there. Can you rephrase?

Basically, I think that without contexts, PSK+ServerCert modes like MT
proposed (for 0-RTT with server certificate auth) run into cryptographic
issues.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Schedule (PRs #453, #454).

[Eric Rescorla]

Sorry, I think you lost me there. Can you rephrase?

-Ekr


On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara 
wrote:

> On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote:
> > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> > >
> > > Just one thing to be careful of: If one has off-handshake counter-
> > > keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash
> > > those in, or one gets all kinds of crypto screw (which may or may not
> > > be actually exploitable...)
> > >
> > > The "context identifier" looks real handy for that purpose..
> >
> >
> > Yep. We were thinking that too!
> >
> >
> > Thanks for the quick look.
>
> In very quick'n'dirty security analysis the other thing I noticed was
> that if server handshake needs something to be nonce w.r.t. "SS", (e.g.
> happens in GDHE-PSK-CERT modes MT posted I-D about), you need contexts
> anyway, even with just "SS" being PSK.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Key Schedule (PRs #453, #454).

[Ilari Liusvaara]

On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> 
> An additional nice point about this design is that it easily
> accomodates additional keys. For instance, if we had some post-quantum
> key exchange method, we could easily add its key in the final
> Add-Secret or add an extra Add-Secret stage before HS. Similarly, if
> we had a long-term DH key as in OPTLSv1, it could replace the 0 in the
> final Add-Secret.

Just one thing to be careful of: If one has off-handshake counter-
keys[1] (like the now-removed GDH 0-RTT mode had), one needs to hash
those in, or one gets all kinds of crypto screw (which may or may not
be actually exploitable...)

The "context identifier" looks real handy for that purpose...
 
> CONTEXT IDENTIFIER
> 
> The resumption_psk is then used as the PSK for resumption and the
> resumption_context is added to the hash of the handshake messages
> whenever you use them, currently just by appending to the hash, as in:
> 
>Hash(handshake messages) +resumption_context
> 
> This is used *both* to derive the keys and for the input to
> the CertificateVerify/Finished. For convenience, I've

Oh, even better than the original "contexts" proposal, as this is
non-checked. As said, if you ever need off-handshake counterkeys
(as above, and you most probably do for adding any sort of realistic
post-quantum capabilities[2]), this looks real handy for mixing those
in.


[1] Any server-side key that isn't explicitly sent as part of the hand-
shake (most probably having been sent before in prior handshake) but
still is involved in the handshake.

[2] There does exist PQ Key Agreement, but it currently just provoded by
one system that is relatively slow (through not completely impractical)
and severly underanalyzed (major problem).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Key Schedule (PRs #453, #454).

[Eric Rescorla]

PR: https://github.com/tlswg/tls13-spec/pull/454

I have uploaded a PR [technically two PRs, but one builds on the
other, so easier to just read the composition] which resolves two out
of the three significant remaining crypto issues (the remaining one is
the long-running discussion of post-handshake keys). The following
message lays out the changes, which are:

- Adopt a more linear key schedule
- Add a context identifier for resumption


KEY SCHEDULE
We had a lot of comments that the existing key schedule was too hard
to understand and implement and could be simplified under the
assumption that keys were available in a specific order (PSK then DH
ZZ). I've been working together with Karthik, Hugo, Antoine, and
others to produce something cleaner. (Note: I believe they consider
this acceptable, but that doesn't mean they wouldn't have designed
every piece exactly as I have.)


The overall key schedule looks like this:

 0
 |
 v
   PSK ->  HKDF-Extract
 |
 v
   Early Secret  --> Derive-Secret(., "early traffic secret",
 | ClientHello)
 | = early_traffic_secret
 v
(EC)DHE -> HKDF-Extract
 |
 v
  Handshake
   Secret -> Derive-Secret(., "handshake traffic secret",
 | ClientHello + ServerHello)
 | = handshake_traffic_secret
 v
  0 -> HKDF-Extract
 |
 v
Master Secret
 |
 +-> Derive-Secret(., "application traffic secret",
 | ClientHello...Server
Finished)
 | = traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Client Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_secret

  Derive-Secret(Secret, Label, Messages) =
   HKDF-Expand-Label(Secret, Label,
 Hash(Messages) + resumption_context, L))


Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons
indicated below. If a key is missing you just use 0s.

The general pattern here is that the secrets shown down the left side
of the diagram are just raw entropy without context, whereas the
secrets down the right side include handshake context and therefore
can be used to derive working keys without additional context.  All
the working keys (both encryption keys and finished keys) are
generated using HKDF-Expand-Label off of the traffic secrets.

This design is motivated by the following principles:

- Separate out adding entropy from adding context.
- Incorporate the transcript once and then derive from there.
- Have a narrow, consistent interface for generating the leaf keys
  so they can just start with a base key.
- Derive from keys as soon as practical so that you can destroy them
  (thus the final call to Add-Secret, which isolates the
  Finished keys from the MS).

An additional nice point about this design is that it easily
accomodates additional keys. For instance, if we had some post-quantum
key exchange method, we could easily add its key in the final
Add-Secret or add an extra Add-Secret stage before HS. Similarly, if
we had a long-term DH key as in OPTLSv1, it could replace the 0 in the
final Add-Secret.

One thing I want to call out explicitly is that we are using
HKDF-Expand-Label with the output of HKDF-Expand-Label. This is
cryptographically fine, but means that you need an implementation of
the individual HKDF Expand/Extract primitives. As far as I can tell,
this isn't a hardship for anyone, but please speak up if it is. The
advantage of this is that you remove unnecessary crypto operations.


CONTEXT IDENTIFIER
PR: https://github.com/tlswg/tls13-spec/pull/454

Hugo and Karthik both independently suggested that it would be nice to
have some identity/context bound into the PSK handshake. The second PR
accomodates that by deriving two values from the RMS:

   resumption_psk = HKDF-Expand-Label(resumption_secret,
  "resumption psk", "", L)

   resumption_context = HKDF-Expand-Label(resumption_secret,
  "resumption context", "", L)

The resumption_psk is then used as the PSK for resumption and the
resumption_context is added to the hash of the handshake messages
whenever you use them, currently just by appending to the hash, as in:

   Hash(handshake messages) +resumption_context