On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > Regardless of whether we make this change though, I think it would be > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > generated by the handshake. During the connection lifetime, we generate > a series of record encryption keys: handshake and application keys for > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. > None of these keys should be used outside their intended use cases in a > single connection. The only cross-connection secret specified in the > protocol is the resumption master secret, and if applications want a > key from TLS 1.3, they must only use the exporter master secret. All > other keys are internal to TLS.
I think TLS 1.3 RFC should specify what the protocol looks like and how it can be used from application perspective. This includes specifying what keys can be exported (among many other things, like how authentication can be performed). I agree that exporting the main encryption keys or secrets those are derived from for any purpose is a rotten idea. If you need keying or authentication material, use TLS EXPORTER (tls-unique is deprecated) with requirement to use EMS on prior versions[1]. Then one might need to export RMS. I think it should be exported as blob that also contains other associated information (e.g ciphersuites). And possibly also encrypted, using some MRAE algorithm. [1] Compatiblity hack: One might consider EMS always negotiated when TLS 1.3 is negotiated. This could prvent applications that do know about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3. That is, if application asks about TLS 1.3 (ServerVersion 3.4) connection "is EMS enabled?" the answer will be always "yes" (since the point of that check is to exclude THS attacks, and TLS 1.3 already excludes those on baseline). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
