[TLS] IETF TLS WG <tls@ietf.org>

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 24 February 2016 21:00 UTC

To: Andrei Popov <Andrei.Popov@microsoft.com>
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Message-ID: <56CE19F5.2050101@KingsMountain.com>
Date: Wed, 24 Feb 2016 13:00:37 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NZF89HjqdSD5rueAu1rPxtlb9wA>
Cc: IETF TLS WG <tls@ietf.org>
Subject: [TLS] IETF TLS WG <tls@ietf.org>
Precedence: list

 > 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:tls-bounces@ietf.org] On Behalf Of =JeffH
 > Sent: Tuesday, February 23, 2016 4:31 PM
 > To: Ilari Liusvaara <ilariliusvaara@welho.com>
 > Cc: IETF TLS WG <tls@ietf.org>
 > 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
 > TLS@ietf.org
 > 
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] IETF TLS WG <tls@ietf.org> =JeffH