Unless I'm wrong, with the visibility draft the client side is also unable to identify who the key material is being transferred to. Only the server-side can know it, so I think it's a similar case.
Imagine a malicious user is able to subvert the communication between the server and the middlebox. If this user manages to convince the server that it should use its own keys instead of the ones the middlebox owns, the attacker is able to happily decrypt all traffic by using a mechanism we have provided him with, and nobody would realize it (because the client has no way to know who the key material is being shared with) And yes, if the key material is shared out-of-band we have a similar problem, I don't deny it. I think that this comes down to a philosophycal dylemma.. We have two different mechanisms that amount to a similar security level: - key material is shared out-of-band using some additional mechanism, defined outside of TLS - key material is shared in-band using the TLS extension Both mechanisms seem to provide, in theory, similar security levels. The difference is that if TLS extensions handle it, it's TLS the responsible for the security downgrade, whereas in the other case... well, we can't prevent anyone from doing what they want with their key material so... I would vote for out-of-band sharing if enterprises need it, delegating this in a completely different protocol. TLS should be as clean and as secure as possible. ________________________________ De: TLS <tls-boun...@ietf.org> en nombre de Yoav Nir <ynir.i...@gmail.com> Enviado: jueves, 15 de marzo de 2018 23:49 Para: Rich Salz Cc: tls@ietf.org Asunto: Re: [TLS] TLS interception technologies that can be used with TLS 1..3 Yeah, as log as we know who we're shipping it to and the user intends for us to send it to this entity. For the debugging case that we were talking about in Prague, sending the keys out-of-band should work fine. For some middlebox that needs to decrypt the traffic online, it needs the keys before the first data record goes out. I don't see how we can do that without interleaving it with the handshake. On 16 Mar 2018, at 0:42, Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: I think if we ship the keys over some kind of secure socket layer we should be okay, right? From: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>> Date: Thursday, March 15, 2018 at 6:41 PM To: Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> Cc: Rich Salz <rs...@akamai.com<mailto:rs...@akamai.com>>, Hubert Kario <hka...@redhat.com<mailto:hka...@redhat.com>>, "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3 IIUC not quite. There is an API, so the application that uses the library can get the keys. The application can then save it to a file, send it to a central repository, send it to the government, or whatever else it might want to do. There is no built-in setting where OpenSSL writes the keys to a file, nor do applications such as web servers do this AFAIK. It should not be difficult to write, but is not provided in off-the-shelf software. Making the library send this in-band in some protocol extension is a far bigger endeavor. It's also a dangerous switch to leave lying around. On 16 Mar 2018, at 0:16, Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> wrote: Just to confirm that I understand the scope of the discussion here: - TLS libraries have facilities to export keys from the library - Obviously, it's possible to ship these exported keys elsewhere (`tail -f $SSLKEYLOGFILE | nc $LOGBOX`) So all we're really talking about is whether to define a way to do the shipment of the exported keys in-band to the TLS session. On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: This is what OpenSSL provides: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback..html _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
