> 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.
Thanks Andrei, the above confirms my own assessment/suspicions.
=JeffH
> -----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
