Subject: [TLS] HSM-friendly Key Computation

From: Russ Housley <[email-masked]>
Date: Fri, 17 Apr 2015 14:59:30 -0400

Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from the current master secret (MS).  First a key block is computed:

      key_block = PRF(MS,
                      "key expansion",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random);

Then, the key block is divided into keys and IVs:

      client_write_key[SecurityParameters.enc_key_length]
      server_write_key[SecurityParameters.enc_key_length]
      client_write_IV[SecurityParameters.fixed_iv_length]
      server_write_IV[SecurityParameters.fixed_iv_length]

If one wants to implement the cryptographic functions in a Hardware Security Module (HSM), this structure is far from ideal.  In general I would expect the client_write_key and server_write_key to stay inside the protected boundary of the HSM, but the client_write_IV and server_write_IV do not need this protection.  Both of these coming from the same key_block makes this separation very difficult to implement.

Can we get these values from different invocations of the PRF?  I'd like to see one invocation for values that are expected to remain secret and a separate invocation for values that do not need to remain secret.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Apr 2015 12:40:25 -0700

We should defer this issue until we know whether we are generating an IV
at all.

-Ekr

On Fri, Apr 17, 2015 at 11:59 AM, Russ Housley <[email-masked]> wrote:

> Section 6.3 of draft-ietf-tls-tls13-05 describes the key calculation from
> the current master secret (MS).  First a key block is computed:
>
>       key_block = PRF(MS,
>                       "key expansion",
> If one wants to implement the cryptographic functions in a Hardware
> Security Module (HSM), this structure is far from ideal.  In general I
> would expect the client_write_key and server_write_key to stay inside the
> protected boundary of the HSM, but the client_write_IV and server_write_IV
> do not need this protection.  Both of these coming from the same key_block
> makes this separation very difficult to implement.
>
> Can we get these values from different invocations of the PRF?  I'd like
> to see one invocation for values that are expected to remain secret and a
> separate invocation for values that do not need to remain secret.
>
> Russ
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Apr 2015 12:44:59 -0700

Note also that this is a known issue.  Mike StJohns raised it previously.

https://github.com/tlswg/tls13-spec/issues/5

On 17 April 2015 at 12:40, Eric Rescorla <[email-masked]> wrote:
>> Security Module (HSM), this structure is far from ideal.  In general I would
>> expect the client_write_key and server_write_key to stay inside the

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 17 Apr 2015 23:00:00 +0300

On Fri, Apr 17, 2015 at 02:59:30PM -0400, Russ Housley wrote:
> Security Module (HSM), this structure is far from ideal.  In general
> I would expect the client_write_key and server_write_key to stay
> inside the protected boundary of the HSM, but the client_write_IV
> and server_write_IV do not need this protection.  Both of these
> coming from the same key_block makes this separation very difficult
> to implement.

While if the encryption algorithm is strong, there is no real
difference between public and private nonces (if algorithm is not
strong, then all bets are off), having untrusted parts pick nonces
with non-MR AE (especially something so hair trigger as AES-GCM)
seems like asking for trouble.

> Can we get these values from different invocations of the PRF?
> I'd like to see one invocation for values that are expected to
> remain secret and a separate invocation for values that do not
> need to remain secret.

That would certainly work. Note that to implement full TLS, one
already needs to derive "public" values out of "private" ones.

On another thought, TLS library authors might not appreciate
key expansion being changed (nor KDF changes)...

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Fri, 17 Apr 2015 23:32:22 +0300

> On Apr 17, 2015, at 10:40 PM, Eric Rescorla <[email-masked]> wrote:
> 

The client_write_iv and server_write_iv are needed, and I’m not aware of any contention about them. In AES-GCM they are used for the “salt” value, and the chacha20-poly1305 draft uses the same terminology for a 32-bit fixed part of the nonce that is derived from the key buffer.

This is not the same as the per-record IV that we *are* considering dropping.

Yoav

---

From: Brian Smith <[email-masked]>
Date: Fri, 17 Apr 2015 11:18:12 -1000

> This is not the same as the per-record IV that we *are* considering dropping.

I think you're misunderstanding what is being discussed. As far as I
know, nobody objects to using the record sequence number in a way that
turns the nonce into a counter. The only thing being debated is
whether client_write_iv and server_write_iv are used. See the actual
pull request [1]. The proposal put forth in that pull request is that
the nonce will consist *only* of the per-record sequence number,
padded with zeros, and without the part that was comprised of
client_write_iv and server_write_iv.

Cheers,
Brian

[1] https://github.com/ekr/tls13-spec/commit/0c610a9453ca10bd12d3b979d2faa014a0b12251

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Apr 2015 15:14:27 -0700

That's correct. Yoav, if you're sad about that, then now is the time to say
that :)

-Ekr

On Fri, Apr 17, 2015 at 2:18 PM, Brian Smith <[email-masked]> wrote:

> > The client_write_iv and server_write_iv are needed, and I’m not aware of
> any contention about them. In AES-GCM they are used for the “salt” value,
> and the chacha20-poly1305 draft uses the same terminology for a 32-bit
> fixed part of the nonce that is derived from the key buffer.
> >
> [1]
> https://github.com/ekr/tls13-spec/commit/0c610a9453ca10bd12d3b979d2faa014a0b12251
>

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 19 Apr 2015 04:22:59 +0000

Russ Housley <[email-masked]> writes:

>If one wants to implement the cryptographic functions in a Hardware Security
>Module (HSM), this structure is far from ideal.

Weelll... it's far from ideal if you want to use traditional/historic PKCS #11
mechanisms, but since a new PRF will need updated HSM support anyway it
shouldn't be any problem to accommodate it, and now that PKCS #11 is being
managed by OASIS rather than RSADSI/EMC and things have got moving again in
advancing the spec, it shouldn't be that big a deal.  If you look at how
CKM_TLS_PRF works, it's a significant change from how C_DeriveKey() normally
functions that was made in order to accommodate how TLS wants to do things.
For the TLS 2.0 (a.k.a. 1.3) PRF the PKCS #11 folks can make the same
accommodation.  It's an issue for the HSM vendors to adapt, not the TLS spec
to adapt.

Peter.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Sun, 19 Apr 2015 10:27:14 +0200

Hi,

> On 19 Apr 2015, at 06:22, Peter Gutmann <[email-masked]> wrote:
> 
> shouldn’t be any problem to accommodate it
…
>   It's an issue for the HSM vendors to adapt, not the TLS spec
> to adapt.

I agree with Peter. Anyway, everyone will have to spend some time and money to update their HSMs at some point.
That said, if we can sync all major changes in a batch, we should try to do so.

But in general it should not be our concern, else we can never improve the crypto and the protocol.
Cheers,

B.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 19 Apr 2015 14:49:58 -0400

On 4/19/2015 12:22 AM, Peter Gutmann wrote:
> mechanisms, but since a new PRF will need updated HSM support anyway

And that's where we differ I think.
> it

It's not exactly that.   If you go back and look at PKCS11 2.20 , you'll 
note that they just placed the TLS/SSL  functionality in by rote - 
mainly by hacking the PKCS11 mechanism construct to provide a way of 
outputting multiple keys.

There are actually SSL mechanisms:

CKM_SSL3_MASTER_KEY_DERIVE
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_SSL3_PRE_MASTER_KEY_GEN
CKM_SSL3_MASTER_KEY_DERIVE_DK

And TLS mechanisms

CKM_TLS_PRE_MASTER_KEY_GEN
CKM_TLS_MASTER_KEY_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_TLS_MASTER_KEY_DERIVE_DH

They also handily provided the CKM_TLS_PRF  mechanism which basically 
allowed you to extract ANY key stream material from a given master 
secret (since all the bytes from a call using this mechanism were 
provided nicely packaged in the place specified in the mechanism 
structure).  But that was as was requested by TLS implementers and 
probably didn't get enough vetting by the security deep thinkers.

CKM_SSL_KEY_AND_MAC_DERIVE, CKM_TLS_KEY_AND_MAC_DERIVE and CKM_TLS_PRF 
are insecure in that they allow trivial extraction of material from a 
derived key stream.   That is an artifact of multiple things:  how the 
TLS KDF function is currently defined, the use of key exporters with out 
a model for cryptographic separation; the use of TLS specific functions.

PKCS11 tries to fix the worst of these in the new version when it added 
support for TLS1.2: 2.40 deprecates CKM_TLS_PRF, adds a CKM_TLS_MAC 
function for signing the finished messages, deprecates 
CKM_TLS_KEY_AND_MAC_DERIVE in favor of CKM_TL12_KEY_SAFE_DERIVE. There 
is a CKM_TLS12_KEY_AND_MAC_DERIVE, but it comes with a black box 
warning.  Its there only because the current AEAD suites require a 
source of session nonce information and they get it from the IV production.

What I would love to see for TLS1.3 is NO TLS specific mechanisms being 
added to PKCS11.    That if we still sign the finished message, we use a 
true MAC function.  That if we derive keys, we use a bog standard KDF.  
That we stomp on every TLS specific twist unless there is a specific 
security need to keep TLS secure.

At this point the set of KDFs in PKCS11 is very protocol specific and 
constitute a good part of the non-common mechanisms.  Most of the rest 
seem to relate to one family or another (e.g. suite b, GOST, etc).  It 
would be great if we could pick a standardized KDF of family of KDFs for 
the IETF and not go through this again.

Mike

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Apr 2015 09:42:43 +0300

On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote:
> true MAC function.  That if we derive keys, we use a bog standard KDF.  That
> we stomp on every TLS specific twist unless there is a specific security
> need to keep TLS secure.

Not possible. There are features (e.g. extractor and resumption/unique
interaction) that can't be feasibly removed (or even deprecated) and which
need PRF'ing secret keys into public data.

Also, true MAC functions just aren't enough for some places (such as
deriving the various master secrets or unique value).

-Ilari

---

From: "StJohns, Michael" <[email-masked]>
Date: Mon, 20 Apr 2015 12:09:56 -0400

On Monday, April 20, 2015, Ilari Liusvaara <[email-masked]>
wrote:

> That

I'm not quite sure how you've come to this conclusion.  The underlying
function for a KDF is generally a MAC function which by definition produces
public data.  It's only when bound into a KDF that it by definition
produces secret data.  The main problem we've encountered is that we use
the same key to produce public (IV) data and private key material.   Fixing
this is more an issue of how to cryptographically isolate products of the
diverse operations in a way that enhances security.

Replacing the current functions with off the shelf ones along with a few
tweaks to the key derivation mixins and key tree can be done without
removing any functionality.

Mike

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Apr 2015 19:37:55 +0300

> diverse operations in a way that enhances security.

Maybe I used bad terminology, but...

There are other places in TLS that fundamentally need to (indirectly) derive
public data out of secret key material.

E.g. extractor and unique/resumption-interaction. There might be others as
well.

-Ilari

---

From: Robert Relyea <[email-masked]>
Date: Wed, 22 Apr 2015 10:02:50 -0700

> public data out of secret key material.
That's not a a problem. The problem is using the same mechanism to 
derive the public data that we use to derive the keys.
It's even OK to use the same secret key for both (from an HSM POV).

What Michael is saying is that there are existing functions for both KDF 
(secret material -> key) and Mac (secret material-> unique public data). 
He's requesting that TLS not have it's own versions of these functions.

So there are really 3 things being discussed here and there is some 
conflation:

1) The use of the same mechanism to create both secret and public data. 
This is the most serious issue because there is no work around for 
HSM's, today people with access to HSM's can use the existing mechanism 
for IV to leak actual keys protected by the HSM.
2) The use of a single mechanism to generate multiple keys (and IVs) in 
a single operation. This isn't HSM pain, it's more a PKCS #11 pain. I 
think this is more of a 'cleanliness' issue. PKCS #11  may still choose 
to provide a single mechanism for performance reasons.
3) The use of yet another KDF and MAC. The world has lots of KDF's and 
MAC's out there, we does TLS need another. I'm a bit ambivalent about 
this. In an ideal world we would all use the same KDFs rather than 
inventing a new one for each protocol. On the other hand TLS is a big 
enough fish I don't see a big issue having it's own. I'd rather someone 
propose exactly what other KDF TLS would use. Currently I don't support 
many KDF's myself, TLS being the main one.

For me 1) is the only show stopper, 2 and 3 are basically bike shedding 
(though I admit we are talking some pretty ugly bike sheds;).

bob

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Apr 2015 20:35:26 +0300

On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
> That's not a a problem. The problem is using the same mechanism to derive
> the public data that we use to derive the keys.

So would using two different PRF functions, one for parts that don't
downgrade and another for parts that do downgrade (e.g. IV derivation,
unique / finished calculations, exporter calculations, etc..) solve the
issue?

(Of course, the two functions should be closely related, so not to
annoy software implementations too much)...

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2015 13:37:45 -0400

If we're using HKDF-Extract, can we just key off different labels?

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Wed, 22 Apr 2015 17:30:42 -0400

> If we're using HKDF-Extract, can we just key off different labels?

Basically, no.

The Extract function is really not designed to be used standalone but as 
a way of concentrating entropy for input to the expansion phase.  Its 
dangerous to talk of these functions as separately callable.  They are 
steps not separate functions.

  The extract step's only non-key input - salt - is not the same as the 
"info" input used in the expand phase - 'salt' is supposed to be missing 
or random,  not a fixed string like a label.

"info" is where the various labels go and that's only present in the 
expand phase.

What you want to do is specify as part of the mixins (e.g. 'info' - e.g. 
the collection of label and context)  a set of fields that describe 1) 
how the key stream is going to be broken up (eg. lengths of the sub 
keys), 2) what algorithms will use each of the parts of the key stream, 
and 3) whether or not those parts are allowed to be exported/extracted.

A software module will basically ignore these because - really - its all 
the same memory although it should really make sure the key lengths and 
types matc.  An HSM will look at these and be able to make policy 
decisions for protection of the segments (e.g. preventing export of 
material that was created to be non-exportable).

Having all of these in the mixins means that the key stream expansion 
completely changes if ANY of these mixins change which in turn means  
that the various ways you can use to extract truly secret key material 
(as differentiated from exportable material) from an HSM using the 
currently defined mechanism can be eliminated.  (I can explain my 
reasoning if necessary).

Mike

>
> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Apr 2015 19:03:05 -0400

> If we're using HKDF-Extract, can we just key off different labels?
Sorry, read that as "HKD-Expand".

-Ekr

> Basically, no.
>
> The Extract function is really not designed to be used standalone but as a
> way of concentrating entropy for input to the expansion phase.  Its
> "info" input used in the expand phase - 'salt' is supposed to be missing or
> random,  not a fixed string like a label.
>
> the collection of label and context)  a set of fields that describe 1) how
> the key stream is going to be broken up (eg. lengths of the sub keys), 2)
> what algorithms will use each of the parts of the key stream, and 3)
> whether or not those parts are allowed to be exported/extracted.
>
> types matc.  An HSM will look at these and be able to make policy decisions
> for protection of the segments (e.g. preventing export of material that was
> created to be non-exportable).
>
> completely changes if ANY of these mixins change which in turn means  that
> the various ways you can use to extract truly secret key material (as
> differentiated from exportable material) from an HSM using the currently
> defined mechanism can be eliminated.  (I can explain my reasoning if
> necessary).
>
>
> Mike
>
>
>
>
>> derive
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Apr 2015 11:42:01 +0300

On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
> What you want to do is specify as part of the mixins (e.g. 'info' - e.g. the
> collection of label and context)  a set of fields that describe 1) how the
> key stream is going to be broken up (eg. lengths of the sub keys), 2) what
> algorithms will use each of the parts of the key stream, and 3) whether or
> not those parts are allowed to be exported/extracted.

In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is seed,
right?

So inside that (or whatever the equivalent), serialize:
- Label
- Lengths, types and exportable flags of subkeys
- Context

?

Properly serializing that would avoid the well-known TLS 1.2 screwup in
PRF defintion (which got copied to "dh based key exchange" draft).

One possible structure in TLS notation:

struct prf_output
{
     /*
     0x0000 => For key derivation
     0x0001 => For AEAD keying
     0x8002 => For AEAD IV
     0x8003 => For octet string (exporters, unique)
     */
     uint16 type;
     uint16 length;  /* In bytes. */
};

struct prf_seed
{
     opaque label<0..65535>
     prf_output outputs<4..65532>
     opaque context<0..65535>
};

Fixed expansion is 6 bytes and each subkey is 4 bytes.

The key expansion for AES-256-GCM a'la TLS 1.2 would look like:

00 0d 6b 65 79 20 65 78 70 61 6e 73 69 6f 6e
00 10 00 01 00 20 00 01 00 20 80 02 00 04 80 02 00 04
00 40 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Where XX is the random data. One can see this extracts total of 72
bytes. 

TLS 1.2 extended master secret with SHA-256 prf-hash looks like:

00 16 65 78 74 65 6e 64 65 64 20 6d 61 73 74 65 72 20 73 65 63 72 65 74
00 04 00 00 00 30
00 20 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

Where XX is the session hash up to that point. Output size can be seen
to be 48 bytes.

Also, it occurs to me that if PRF has salt input (like HKDF), one should
stick something non-secret but variable there (e.g. client random, or
suitable handshake hash, or something). Some outputs share a (key,salt)
pair. Keys should be combined by serialization.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2015 05:54:02 -0400

On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara <
[email-masked]> wrote:

> the

Can elaborate on this?

The DH-based key exchange draft uses HKDF and uses separate
labels for each use of HKDF-Expand so that (for instance) exporters
and key generation have different labels.

> suitable handshake hash, or something).

Based on talking to Hugo, my understanding is that the best way
to do this is by incorporating the handshake hash at the HKDF-Expand
stage, as in:

client_write_key = HKDF-Expand(Secret, "client write key" + session_hash,
                                 SecurityParameters.enc_key_length)

Some outputs share a (key,salt)
> pair. Keys should be combined by serialization.

If you're referring to how we combine (say) the static DH and the ephemeral
DH, what we had discussed was running K1 through HKDF-Extract to
generate PRK1 and then using PRK1 as the salt for HKDF-Extract on
PRK2. I.e.,

   PRK1 = HKDF-Extract(0, K1)
   PRK2 = HKDF-Extract(0, K2)

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Apr 2015 14:02:14 +0300

> and key generation have different labels.

The label+seed thing.
 
>                                  SecurityParameters.enc_key_length)

Except that now nothing preturbs the secret extraction. Even HKDF RFC
says things like "adds significantly to the strength" and "strengthening
the analytical results that back[...]design".

Also, in where I try to work the simplest key derivation that I think
will work at all (supports 0RTT and (DHE-)PSK, but not fixedDH), I have:

[...]
master_secret = PRF(premaster_secret, "TLS1.3 master secret", hash_1)
[...]
client_hs_key = PRF(master_secret, "Client Key expansion")
[...]
client_app_key = PRF(master_secret, "Client Key expansion", hash_5)
[...]

hash_1 is hash of unencrypted parts, hash_5 is hash of the entiere
handshake. One can stick hash_1 into client_hs_key derivation if one
wants to (but it is still needed in master_secret).

(the rekeying is to deal with kp attacks from key exchange or if
somebody does dumb things with DTLS).

Also, if it had client_application_master_secret, then derivation
of that would have the hash_5.

> > pair. Keys should be combined by serialization.

Ah, I just remembered what the "Keys should be combined by serialization."
meant: If one has multiple keys one needs to feed in, one should serialize
those into a block and then feed that as a key input (not doing things
like feeding secret keys as salts).

The "Some outputs share a (key,salt) pair." means that there may be places
where multiple keys are derived at the same point out of the same master key.

E.g. on the thingy I was working on, there are 3 keys using (MS,hash3) and
2 using (MS,hash5). And if there is no client certificate, hash3=hash5.

>    PRK2 = HKDF-Extract(0, K2)

AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who
described how to do 0RTT in simpler way.

Also, maybe the only interesting application of FixedDH is deniable
key exchange. Except that supporting that would cause major issues
elsewhere (and "DH based key exchange" is not deniable).

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Apr 2015 13:03:51 -0400

On 4/22/2015 7:03 PM, Eric Rescorla wrote:
>
>
> On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
Actually, use HKDF as the term with no expand or extract suffix.

Mike

>
> -Ekr
>
>
>     Basically, no.
>
>     The Extract function is really not designed to be used standalone
>     but as a way of concentrating entropy for input to the expansion
>     phase.  Its dangerous to talk of these functions as separately
>     callable.  They are steps not separate functions.
>
>      The extract step's only non-key input - salt - is not the same as
>     the "info" input used in the expand phase - 'salt' is supposed to
>     be missing or random,  not a fixed string like a label.
>
>     "info" is where the various labels go and that's only present in
>     the expand phase.
>
>
>     What you want to do is specify as part of the mixins (e.g. 'info'
>     - e.g. the collection of label and context)  a set of fields that
>     describe 1) how the key stream is going to be broken up (eg.
>     lengths of the sub keys), 2) what algorithms will use each of the
>     parts of the key stream, and 3) whether or not those parts are
>     allowed to be exported/extracted.
>
>     A software module will basically ignore these because - really -
>     its all the same memory although it should really make sure the
>     key lengths and types matc.  An HSM will look at these and be able
>     to make policy decisions for protection of the segments (e.g.
>     preventing export of material that was created to be non-exportable).
>
>     Having all of these in the mixins means that the key stream
>     expansion completely changes if ANY of these mixins change which
>     in turn means  that the various ways you can use to extract truly
>     secret key material (as differentiated from exportable material)
>     from an HSM using the currently defined mechanism can be
>     eliminated.  (I can explain my reasoning if necessary).
>
>
>     Mike
>
>
>
>>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Apr 2015 13:34:53 -0400

> - Lengths, types and exportable flags of subkeys

Pretty much.
>       uint16 length;  /* In bytes. */

I ended up with a bit larger set of key types:

Master Secret (can only be used with KDFs)
AES-CMAC
AES-AEAD
AES-ENCRYPT
HMAC-SHA1
HMAC-SHA2
GENERIC-DATA (different that PKCS11 generic secret - could be IV 
material for example).

as a starting point.

It turns out that you want to subdivide AES AEAD uses from non AEAD AES 
functions because you don't want to be able to use AES-CTR to get around 
the AES-CCM and GCM "don't let the data come out unless its been 
verified" policy.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Apr 2015 20:52:44 +0300

> Master Secret (can only be used with KDFs)

Right.

> AES-CMAC

Not used anywhere (insufficient security).

> AES-AEAD

Is there ment to be XXX-AEAD for different encryption algorithms?
Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?

> AES-ENCRYPT

Not used. Encryption always pairs with authentication (AEAD).

> HMAC-SHA1

A NULL cipher key? That one wouldn't be directly used for anything else.

> HMAC-SHA2

NULL cipher keys are per algorithm?

> GENERIC-DATA (different that PKCS11 generic secret - could be IV material
> for example).

This is "octet string" above (except IVs are "AEAD IV").

> as a starting point.

Depending on view, you also need special type for exporter secret, since
it behaves somewhat unlike others.

> functions because you don't want to be able to use AES-CTR to get around the
> AES-CCM and GCM "don't let the data come out unless its been verified"
> policy.

As said, encryption always pairs with authentication.

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Apr 2015 15:01:37 -0400

> Not used anywhere (insufficient security).

For this and the comment below..... I'm not just thinking about TLS.  
And I am thinking about how to retrofit this to TLS1.2 which doesn't 
require this to be an AEAD function.  And then there's the composed AEAD 
suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So 
while they may not be used by TLS directly, I want to get code points 
for all the possibilities.
> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?

Generally yes for xxx-aead having different types per algorithm. Because 
you don't want to (for example) be able to use material for both AES and 
say GOST.   For modes, AEAD modes are mostly supersets or combinations 
of non-AEAD modes and there's an attempt to enforce "releasability only 
after verification" type policies on the CCM and GCM modes.   It would 
be good to have different codes for CCM and GCM (or even other modes), 
but I don't know that adds markedly to security.
> Not used. Encryption always pairs with authentication (AEAD).

See above - one of the questions is how does a composed AEAD suite 
derive subkeys.  Generically it seems to be "split the stream wherever 
you want" and as noted, that has a few problems.
> A NULL cipher key? That one wouldn't be directly used for anything else.

For TLS1.2 and before, being able to tag that you're deriving an 
integrity key...  ditto for below.
> This is "octet string" above (except IVs are "AEAD IV").

Not quite. (<begin pedantic mode>  :-) )

One of the problems we have is a lack of common language.  And IV is one 
of those that's very slippery.

TLS - incorrectly - called what's being produced by the master secret 
expansion an "IV".   What it actually was was the "first IV" of the 
session for cipher suites that included  CBC as a mode and a "session 
nonce" for suites with counter based ciphers.

An IV is the common data injected by both sender and receiver to ensure 
that the same data doesn't encrypt the same way if identical data 
happens to occur in the plaintext stream multiple times.  For counter 
based ciphers, the IV is used with the block counter to form the block 
nonce(s) that (is/are) encrypted to form the XOR key stream.

An counter-based IV  (e.g. for CTR, CCM and GCM) is generally composed 
of the concatenation of the session nonce (or as we've been discussing a 
fixed length of zeros) plus a per-message value (and we've been 
discussing always using the message sequence number as that per-message 
value).

Due to the way TLS is constructed, what comes out of the master secret 
expansion can only be a "first IV" or a session nonce.  It would be 
possible to change this so an expansion is done with each message (e.g. 
same master secret, different mixins such as the sequence number) to 
generate a true per-message IV, but that's expensive and provides little 
security benefit.

</pedantic mode>

> it behaves somewhat unlike others.

I think the easiest way to accomplish this is to use a flag saying 
whether or not its exportable (generally removable from an HSM) that 
gets mixed in.  That way you have the common language of what you want 
to generate and then only have to decide on handling criteria.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2015 16:05:52 -0400

On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara <
[email-masked]> wrote:

> > > > collection of label and context)  a set of fields that describe 1)
> how
> > > the
> > > > algorithms will use each of the parts of the key stream, and 3)
> whether
> > > or

My proposal for HKDF is to have null-terminated labels (in the same
way as for the signing contexts.

> Except that now nothing preturbs the secret extraction.

Can you explain what you mean by "perturbs"? If you include the session hash
it includes the randoms.

> elsewhere (and "DH based key exchange" is not deniable).

It's not FixedDH, it's the servers semi-static DH and the client's
ephemeral.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2015 16:07:17 -0400

> Actually, use HKDF as the term with no expand or extract suffix.

I discussed this extensively with Hugo and Hoeteck and their advice was to
use
them separately in a similar way to what's here (though they suggested a
slightly
different hierarchy which I have to edit in). Perhaps Hugo will weigh in as
to
the reasoning.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Apr 2015 08:18:29 +0300

> Can you explain what you mean by "perturbs"? If you include the session hash

HKDF RFC seems to essentially say 'if you can use salt, do so'

> It's not FixedDH, it's the servers semi-static DH and the client's

Which semi-static DH (x client's ephemeral)?
- Current
- Previous (may not be available!)
- Both

For current, the only even semi-sane use I can come up with is server
fixedDH certs (this input not a good place to stick PSKs if one wants
"unified" something).

For previous, it is useful if 0RTT group can differ from main exchange
group (but server has to signal if this is to be included or not, since
it may not be computable).

(And both for when both of above apply).

Also, it occurs to me that trying to stick keying data into non-key
PRF inputs may not be a good idea...

And the signature looks more complicated in draft "DH based key exchange",
because the params are in the same message as certificate verify, instead
of separate message (where hash would get it instead of having to be
included separatedly).

-Ilari

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 24 Apr 2015 10:13:24 -0700

On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <[email-masked]>
wrote:

> For this and the comment below..... I'm not just thinking about TLS.  And
> I am thinking about how to retrofit this to TLS1.2 which doesn't require
> this to be an AEAD function.  And then there's the composed AEAD suites
> (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So while they
> may not be used by TLS directly, I want to get code points for all the
> possibilities.
>
>>
>>  AES-AEAD
>>>
> say GOST.   For modes, AEAD modes are mostly supersets or combinations of
> non-AEAD modes and there's an attempt to enforce "releasability only after
> verification" type policies on the CCM and GCM modes.   It would be good to
> have different codes for CCM and GCM (or even other modes), but I don't
> know that adds markedly to security.
>
>>
>>  AES-ENCRYPT
>>>
> See above - one of the questions is how does a composed AEAD suite derive
> subkeys.  Generically it seems to be "split the stream wherever you want"
> and as noted, that has a few problems.
>
>>
>>  HMAC-SHA1
>>>
> For TLS1.2 and before, being able to tag that you're deriving an integrity
> key...  ditto for below.
>
>>
>>  HMAC-SHA2
>>>
> expansion an "IV".   What it actually was was the "first IV" of the session
> for cipher suites that included  CBC as a mode and a "session nonce" for
> suites with counter based ciphers.
>
> that the same data doesn't encrypt the same way if identical data happens
> to occur in the plaintext stream multiple times.  For counter based
> ciphers, the IV is used with the block counter to form the block nonce(s)
> that (is/are) encrypted to form the XOR key stream.
>
> An counter-based IV  (e.g. for CTR, CCM and GCM) is generally composed of
> the concatenation of the session nonce (or as we've been discussing a fixed
> length of zeros) plus a per-message value (and we've been discussing always
> using the message sequence number as that per-message value).
>
> I think the easiest way to accomplish this is to use a flag saying whether
> or not its exportable (generally removable from an HSM) that gets mixed
> in.  That way you have the common language of what you want to generate and
> then only have to decide on handling criteria.
>
>
[Joe] I've having trouble understanding what exactly you are designing
here, is it the interface to a specific HSM or is it the TLS 1.3 key
derivation or is it something else? I think we need to make sure that we
have the requirements defined for the TLS 1.3 key derivation.

Its not clear to me what the problem is with just including the context
label, session hash and possibly length.   The context label would
differentiate between derived key material for different purposes.  For
example, public and private data would use different context labels.  One
would also probably want to include the cipher suite ID in the context
label for keys derived for encryption.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Apr 2015 10:28:32 -0700

And I am thinking about how to retrofit this to TLS1.2 which doesn't
require this to be an AEAD function.  And then there's the composed AEAD
suites (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So while
they may not be used by TLS directly, I want to get code points for all the
possibilities.
>> See above - one of the questions is how does a composed AEAD suite
derive subkeys.  Generically it seems to be "split the stream wherever you
want" and as noted, that has a few problems.
>>>> GENERIC-DATA (different that PKCS11 generic secret - could be IV
material
of the concatenation of the session nonce (or as we've been discussing a
fixed length of zeros) plus a per-message value (and we've been discussing
always using the message sequence number as that per-message value).
>> I think the easiest way to accomplish this is to use a flag saying
whether or not its exportable (generally removable from an HSM) that gets
mixed in.  That way you have the common language of what you want to
generate and then only have to decide on handling criteria.

The issue is the hardware has to enforce the usage of the derived keys. I
think this will restrict our encoding significantly,  perhaps turning it
into some bitfields. Asking hardware to understand context labels is going
to make it not hardware anymore.

Of course, there are other approaches that offer most of the gains without
these costs like separate fixed function terminators, or keeping only a few
keys secret.

Sincerely,
Watson Ladd

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Apr 2015 20:53:46 +0300

> > have the requirements defined for the TLS 1.3 key derivation.

It looks to boil down to designing how to encode inputs to the underlying
KDF.

("looks", because I think I am just beginning to figure out what the heck
is actually wanted).

> > label for keys derived for encryption.

Well, in one mail, Mike says that context labels are not enough.

He apparently wants for KDF to take type(s), export flag(s) and length(s)
of key(s) to generate as parameters. And then stuff those to info/seed
field (along label and such).

Also, looks like he would prefer that different encryption algorithms
have different types (e.g. AES-GCM vs. Chacha20-Poly1305).

(Again, the comment above applies).

> to make it not hardware anymore.

Well, most of the "Hardware" here is actually "software", just running on
special-purpose hardware.

> these costs like separate fixed function terminators, or keeping only a few

Fixed function terminators? Also, what keys to keep secret does not fix
things, since there are some fundamential secret->public derivations.

-Ilari

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 24 Apr 2015 17:36:45 -0400

On Thu, Apr 23, 2015 at 4:07 PM, Eric Rescorla <[email-masked]> wrote:

> different hierarchy which I have to edit in). Perhaps Hugo will weigh in
> as to
> the reasoning.
>

​I've just addressed this issue in an email in the
"confirming the room’s consensus: adopt HKDF PRF for TLS 1.3" thread
(it's the first point in the list of issues in that email).

Hugo