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://www.ietf.org/mail-archive/web/tls/current/msg17924.html



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

Reply via email to