Subject: [TLS] TLS interception technologies that can be used with TLS 1.3

From: Watson Ladd <[email-masked]>
Date: Wed, 14 Mar 2018 17:16:30 -0700

One can either use a static DH share, save the ephemerals on the
servers and export them, or log all the data on the servers.

These options don't require any change to the wire protocol: they just
require vendors supporting them. Why don't they meet the needs cited?

Sincerely,
Watson

---

From: Yoav Nir <[email-masked]>
Date: Thu, 15 Mar 2018 06:51:31 +0200

At the risk of stating the obvious, it’s because server owners want to use the same OpenSSL, NSS, SChannel, or whatever you call the Java library that everybody else uses. They’re all widely used, actively maintained, and essentially free.

None of these libraries support any of this functionality.

> On 15 Mar 2018, at 2:16, Watson Ladd <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hubert Kario <[email-masked]>
Date: Thu, 15 Mar 2018 12:38:28 +0100

On Thursday, 15 March 2018 05:51:31 CET Yoav Nir wrote:
> At the risk of stating the obvious, it’s because server owners want to use
> the same OpenSSL, NSS, SChannel, or whatever you call the Java library that
> everybody else uses. They’re all widely used, actively maintained, and
> essentially free.
> 

huh? Sure, it is not nicely packaged in to allow integration with 3rd party 
systems, and sometimes disabled by default, but it's hardly missing...

https://github.com/openssl/openssl/pull/1646

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

https://bugs.chromium.org/p/chromium/issues/detail?id=393477

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Yoav Nir <[email-masked]>
Date: Thu, 15 Mar 2018 20:07:54 +0200

So what’s the flag in openssl.conf that makes it generate a file with all the keys?  There isn’t one.  I guess the presumption is that if there was an RFC it would be easier to get the powers that be to make it happen. It likely needs to be in the main branch to be ubiquitous, because many products come with their own OpenSSL package.

TBH I don’t think an RFC would have that effect. Not every RFC gets implemented.

> On 15 Mar 2018, at 13:38, Hubert Kario <[email-masked]> wrote:
> 
> https://github.com/openssl/openssl/pull/1646 <https://github.com/openssl/openssl/pull/1646>
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format>
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=393477 <https://bugs.chromium.org/p/chromium/issues/detail?id=393477>
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> --
> Regards,
> Hubert Kario
> Web: www.cz.redhat.com <http://www.cz.redhat.com/>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Mar 2018 19:05:56 +0000

This is what OpenSSL provides:
    https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Mar 2018 18:16:04 -0400

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.

---

From: R du Toit <[email-masked]>
Date: Thu, 15 Mar 2018 18:24:23 -0400

(We have many related discussions currently.. this seemed like the most appropriate thread for my response)

Enterprises are asking for out-of-band TLS decryption, per use-cases outlined in draft-fenter-tls-decryption-00 (and others before that). The current proposal for said out-of-band TLS decryption is draft-rhrd-tls-tls13-visibility-01, which requires opt-in from the TLS server by way of a new “TLS Visibility” extension. If draft-fenter has all the requirements and draft-rhd is supposed to be the solution then the implication is that every TLS endpoint in the enterprise datacenter (and possibly outside the datacenter if those TLS endpoints do not enter via some TLS termination node) must support the proposed TLS extension.  I am also assuming that some enterprise key management solution product is already deployed in the datacenter, and that those products remotely manage the full lifecycle of the TLS endpoint RSA keys and certificates.  Summary: all endpoints must change, and all endpoints are managed.

So, why are we not discussing dynamic out-of-band TLS session secret sharing or TLS secret escrow as solutions? (I call it secrets instead of keys because TLS 1.3 gives us the ability to share different parts of the session secret hierarchy, e.g. sharing “client/server_application_traffic_secret0” instead of sharing “Master Secret”).  The secrets would be shared by the actual TLS endpoints, so it requires no changes to TLS.  I do understand that it would introduce new connectivity requirements for datacenter TLS nodes, but that is why I have the paragraph above where I list my assumptions: those nodes would have to change anyway and those nodes are remotely managed.

--Roelof

From: TLS <[email-masked]> on behalf of Hubert Kario <[email-masked]>
Date: Thursday, March 15, 2018 at 7:38 AM
To: <[email-masked]>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

essentially free.

TLS mailing list

[email-masked]

 

-- 

Regards,

Hubert Kario

Web: www.cz.redhat.com

Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic_______________________________________________

TLS mailing list

[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 16 Mar 2018 00:41:36 +0200

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 <[email-masked]> wrote:
> 
> - 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 <[email-masked] <mailto:[email-masked]>> wrote:
>     https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html <https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html>
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Mar 2018 22:42:22 +0000

I think if we ship the keys over some kind of secure socket layer we should be okay, right?

From: Yoav Nir <[email-masked]>
Date: Thursday, March 15, 2018 at 6:41 PM
To: Richard Barnes <[email-masked]>
Cc: Rich Salz <[email-masked]>, Hubert Kario <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

On 16 Mar 2018, at 0:16, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
This is what OpenSSL provides:
    https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Mar 2018 18:45:24 -0400

Well, exactly.  It seems like the following have equivalent security
properties:

- Shipping out each session's keys as lines in SSLKEYLOGFILE over an ECDHE
TLS connection
- Shipping out each session's keys as an ECIES-encrypted package carried in
a TLS extension

Either way, you're doing a DH with the key recipient's public key and using
that to encrypt the keys.

On Thu, Mar 15, 2018 at 6:42 PM, Salz, Rich <[email-masked]> wrote:

> *From: *Yoav Nir <[email-masked]>
> *Date: *Thursday, March 15, 2018 at 6:41 PM
> *To: *Richard Barnes <[email-masked]>
> *Cc: *Rich Salz <[email-masked]>, Hubert Kario <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *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.
>
>
>
> 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.
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 16 Mar 2018 00:49:52 +0200

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 <[email-masked]> wrote:
> 
> 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. <>
> 
>> On 16 Mar 2018, at 0:16, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Thu, 15 Mar 2018 23:26:03 +0000

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 <[email-masked]> en nombre de Yoav Nir <[email-masked]>
Enviado: jueves, 15 de marzo de 2018 23:49
Para: Rich Salz
Cc: [email-masked]
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 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 <[email-masked]<mailto:[email-masked]>> wrote:

From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 15, 2018 at 6:41 PM
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: Rich Salz <[email-masked]<mailto:[email-masked]>>, Hubert Kario <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

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.