On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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]. > This is the intent. I think we would be well-served to state this. 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). Good suggestion. This in fact is what NSS currently does: https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70 -Ekr > > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
