Hi Jeff,

Tls13-11 I-D is not very clear on this, but my reading is that exporter_secret 
is the TLS 1.3 version of the Keying Material Exporters. If this is correct, 
then there are two pieces currently missing: the ability to specify a custom 
label and the ability to mix in application context. I don't know where this 
should live; perhaps RFC 5705 will need to be updated once TLS 1.3 is 
sufficiently baked.

I also presume that exporter_secret (or a similar construction defined in the 
updated RFC 5705) will become the recommended replacement for tls-unique. The 
1.3 key schedule appears to be under discussion, so things might change.

Cheers,

Andrei
 
-----Original Message-----
From: TLS [mailto:[email protected]] On Behalf Of =JeffH
Sent: Tuesday, February 23, 2016 4:31 PM
To: Ilari Liusvaara <[email protected]>
Cc: IETF TLS WG <[email protected]>
Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable 
to TLS 1.3 ?

Hi Ilari,

Ilari replied on Wed, 17 Feb 2016:
 > On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote:
 >> Hi,
 >>
 >> RFC5705 section 4 "Exporter Definition" [1] states..
 >>
 >>    The exporter takes three input values:
 >>
 >>    o a disambiguating label string,
 >>
 >>    o a per-association context value provided by the application using
 >>      the exporter, and
 >>
 >>    o a length value.
 >>
 >>    If no context is provided, it then computes:
 >>
 >>            PRF(...
 >>               )[length]
 >>
 >>    If context is provided, it computes:
 >>
 >>            PRF(...
 >>               )[length]
 >>
 >>
 >> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function)  >> 
 >> from TLS {1.0, 1.1, 1.3}.  Since the PRF() is no longer defined in TLS  >> 
 >> 1.3, RFC5705 is incompatible with TLS 1.3, yes?

[...the above question remains unanswered...]

 >>
 >> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material  
 >> >> exporter (KME) in S 7.1 step 8 [2]..
 >>
 >>    7.1.  Key Schedule
 >>
 >>       [...]
 >>
 >>       8. exporter_secret = HKDF-Expand-Label(master_secret,
 >>                                           "exporter master secret",
 >>                                           handshake_hash, L)
 >>       [...]
 >>
 >>
 >> ..i.e., does the above step "8." effectively define the TLS 1.3 keying  >> 
 >> material exporter?
 >>
 >
 > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably  > 
 > the "master secret" used for calculations is exporter_secret.

agreed -- that is what is being referred to in various msgs on the list as 
"EMS" (exporter master secret?) ?


 > However, just replacing the PRF in definition with the standard TLS 1.3
 > PRF (HKDF) would leave those exporters using randoms, which aren't
 > explicitly used anywhere in TLS 1.3.

hm, I'm not sure I understand.

back on 8-Oct you mused on the below [1]..

One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with:

label: "TLS 1.3 tls-unqiue"
context: No context
Length: 256

And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some
better way at handling both context and no context cases? In original
RFC, those were different):

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, 0x01 | context, L)

or (no context case)

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, <blank>, L)


..where "output" would apparently be the Exported Keying Material value, 
which seems plausible (modulo refining the Label). So I'm not sure 
where/what you meant by "using randoms" above... exporter_secret is not a 
"random", yes?

=JeffH

[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2ftls%2fcurrent%2fmsg17924.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kyi1lG2n6i4M40Uo2p%2bwA%2fi7in%2by1TcgiZcwZbXiIY%3d



_______________________________________________
TLS mailing list
[email protected]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=24nM3SyRy4yzg3lznrwYx5ECzf3ZkJqkRcYWQwlJn20%3d

_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to