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?
>
> 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. 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.
-Ilari
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
