Subject: [TLS] Breaking into TLS to protect customers

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

Some on this list have said that they need to break into TLS in order to protect customers.

The thing customers seem to need the most protection is having their personal data stolen.  It seems to happen with amazing and disappointing regularity on astounding scales.  Some examples include

  *   retailer Target, presumably subject to PCI-DSS rules
  *   Anthem health insurance, presumably a regulated industry
  *   Equifax, a financial-business organization (but apparently not regulated)
  *   Yahoo, a company created on and by and for the Internet (one would think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what benefits and increased protection will customers see?

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Thu, 15 Mar 2018 03:33:48 +0000

Are we going to discuss draft-fenter ad hoc, or we'll start a new thread
dedicated to that? Because I strongly believe I also have some suggestions
for that draft.

ср, 14 мар. 2018 г., 23:30 Salz, Rich <[email-masked]>:

> The thing customers seem to need the most protection is having their
> personal data stolen.  It seems to happen with amazing and disappointing
> regularity on astounding scales.  Some examples include
>
>    - retailer Target, presumably subject to PCI-DSS rules
>    - Anthem health insurance, presumably a regulated industry
>    - Equifax, a financial-business organization (but apparently not
>    regulated)
>    - Yahoo, a company created on and by and for the Internet (one would
>    think they know better)
>
> So what kind of “protect the customer” requires breaking TLS?  And what
> benefits and increased protection will customers see?
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

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

Hi, Rich.

You are conflating customers and users. The customer that may be protected by breaking TLS in a bank’s server farm is the bank itself. An IPS system with visibility into the traffic may detect bots that are there to steal data or mine cryptocurrencies or whatever.

If the customers of the bank are protected, it’s a happy side effect (collateral benefit?). The object is to protect the system integrity and the data.

Yoav

> On 15 Mar 2018, at 5:29, Salz, Rich <[email-masked]> wrote:
> 
> retailer Target, presumably subject to PCI-DSS rules
> Anthem health insurance, presumably a regulated industry
> Equifax, a financial-business organization (but apparently not regulated)
> Yahoo, a company created on and by and for the Internet (one would think they know better)
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: nalini elkins <[email-masked]>
Date: Thu, 15 Mar 2018 08:52:18 +0000

Artyom, yes, as far as I am concerned at least, please start a new thread.
Sorry I am getting behind on responding to all the emails.   But, I am very
interested in what you have to say.  I just can't keep up.   Will do my
best to respond as promptly as possible but there are many of you and not
so many of me.

Nalini

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Thu, 15 Mar 2018 08:53:55 +0000

I fail to see how the current draft can be used to provide visibility to an IPS system in order to detect bots that are inside the bank…

On the one hand, the bot would never opt-in for visibility if it’s trying to exfiltrate data, so this capability would never get activated. And even if the bot was nice enough as to opt-in for visibility, the party responsible for providing the IPS with the required information is the server, which in this case is under control of the attacker. There is no way the attacker’s server will negotiate with the IPS the required keys to decrypt the channel (most likely it can’t even communicate with it).

And if you decide to close that connection because of the lack of visibility, well… 99% of TLS servers in internet will not negotiate visibility keys with your specific IPS, so you could as well close all TLS traffic going outside. And you don’t need visibility for this, only a well-configured firewall.

So, maybe I’m wrong, but I think that this specific use case (analysis of either malicious or legitimate clients’ traffic going from the enterprise network to outside servers) is not covered by the draft under discussion because the remote server will never negotiate the encryption keys with the IPS. For me, the only way to provide visibility within this case is by actively proxying every connection, something that proponents of the need for visibility don’t seem to be comfortable with, and which in my opinion does not require lowering the TLS protocol security level.

Or maybe I misunderstood the use case altogether…

De: TLS [mailto:[email-masked]] En nombre de Yoav Nir
Enviado el: jueves, 15 de marzo de 2018 5:58
Para: Rich Salz <[email-masked]>
CC: [email-masked]
Asunto: Re: [TLS] Breaking into TLS to protect customers

Hi, Rich.

Yoav

On 15 Mar 2018, at 5:29, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

The thing customers seem to need the most protection is having their personal data stolen.  It seems to happen with amazing and disappointing regularity on astounding scales.  Some examples include
·         retailer Target, presumably subject to PCI-DSS rules
·         Anthem health insurance, presumably a regulated industry
·         Equifax, a financial-business organization (but apparently not regulated)
·         Yahoo, a company created on and by and for the Internet (one would think they know better)
We could, of course, go on and on and on.

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

---

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

If I am conflating them, it’s on purpose to draw out the differences.  I’m not an Equifax customer, for example.

The key point in my note is this: how would TLS interception prevent these kinds of things, given that interceptable TLS did not?

From: Yoav Nir <[email-masked]>
Date: Thursday, March 15, 2018 at 12:57 AM
To: Rich Salz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Breaking into TLS to protect customers

Hi, Rich.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 15 Mar 2018 10:59:14 -0400

On Thu, Mar 15, 2018 at 4:53 AM, Ion Larranaga Azcue <[email-masked]> wrote:
> I fail to see how the current draft can be used to provide visibility to an
> IPS system in order to detect bots that are inside the bank…
>
>

In an effort to help clear up the use case and not weighing in on the
discussion...

I think what Yoav is referring to by detecting BOTS within the
network, is really so called advance persistent threat (APT) actors
that are moving around the internal network leveraging existing access
rights of compromised accounts and privilege escalation
vulnerabilities.  These might be detectable with 'visibility'.
Patterns and behavior might be used to detect the APT use case whether
or not encryption protects the stream, but it is more difficult.

If an attacker was using their own server and the fingerprints were
different, detection with encryption would be possible even if it is
more difficult. Threat sharing groups do exchange detection techniques
that involve encrypted traffic for the latter case.  And I think
everyone agrees, that this is not a use case the proponents are trying
to cover.

Best,
Kathleen

>
> On the one hand, the bot would never opt-in for visibility if it’s trying to
> exfiltrate data, so this capability would never get activated. And even if
> the bot was nice enough as to opt-in for visibility, the party responsible
> for providing the IPS with the required information is the server, which in
> this case is under control of the attacker. There is no way the attacker’s
> server will negotiate with the IPS the required keys to decrypt the channel
> (most likely it can’t even communicate with it).
>
>
>
> And if you decide to close that connection because of the lack of
> visibility, well… 99% of TLS servers in internet will not negotiate
> visibility keys with your specific IPS, so you could as well close all TLS
> traffic going outside. And you don’t need visibility for this, only a
> well-configured firewall.
>
>
>
> So, maybe I’m wrong, but I think that this specific use case (analysis of
> either malicious or legitimate clients’ traffic going from the enterprise
> network to outside servers) is not covered by the draft under discussion
> because the remote server will never negotiate the encryption keys with the
> IPS. For me, the only way to provide visibility within this case is by
> actively proxying every connection, something that proponents of the need
> for visibility don’t seem to be comfortable with, and which in my opinion
> does not require lowering the TLS protocol security level.
>
>
>
> You are conflating customers and users. The customer that may be protected
> by breaking TLS in a bank’s server farm is the bank itself. An IPS system
> with visibility into the traffic may detect bots that are there to steal
> data or mine cryptocurrencies or whatever.
>
>
>
> If the customers of the bank are protected, it’s a happy side effect
> (collateral benefit?). The object is to protect the system integrity and the
> data.
>
>
>
> Yoav
>
>
>

-- 

Best regards,
Kathleen

---

From: Carl Mehner <[email-masked]>
Date: Thu, 15 Mar 2018 11:58:53 -0500

> or not encryption protects the stream, but it is more difficult.

Yes, they might, however, the best place for malware detection is on the
edge (which is out of scope for "in the Datacenter" type connections) and
the endpoint, where an agent is able to run that does not need to 'break
in' to the TLS session. Yes, the Fenter draft talks about how malware
endpoints can be anywhere in the network, and that they can delete logs as
a reason to require out of band network decryption. However, if "breaking
TLS" becomes an effective malware mitigation means, more malware makers may
move to using app-level encryption (as some already have). Therefore, the
conclusion we can draw is that malware is not a reasonable reason requiring
this enhanced "visibility".

-carl

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 15 Mar 2018 13:42:20 -0400

On Thu, Mar 15, 2018 at 12:58 PM, Carl Mehner <[email-masked]> wrote:
>
>
> On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty
> <[email-masked]> wrote:
> the endpoint, where an agent is able to run that does not need to 'break in'
> to the TLS session. Yes, the Fenter draft talks about how malware endpoints
> can be anywhere in the network, and that they can delete logs as a reason to
> require out of band network decryption. However, if "breaking TLS" becomes
> an effective malware mitigation means, more malware makers may move to using
> app-level encryption (as some already have). Therefore, the conclusion we
> can draw is that malware is not a reasonable reason requiring this enhanced
> "visibility".

The example I provided is not about malware, it was about lateral
movement by threat actors within a network.  The initial compromise
that led to access within the network may have been through malware or
some other vulnerability, but I do think monitoring on an internal
network (encrypted or not, through logs or on the wire) is the use
case for attack detection that is plausible with the proposed
approach.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ion Larranaga Azcue <[email-masked]>
Date: Thu, 15 Mar 2018 18:08:38 +0000

> -----Mensaje original-----
> De: Kathleen Moriarty [mailto:[email-masked]]
> Enviado el: jueves, 15 de marzo de 2018 18:42
> Para: Carl Mehner <[email-masked]>
> CC: Ion Larranaga Azcue <[email-masked]>; [email-masked]
> The example I provided is not about malware, it was about lateral movement
> by threat actors within a network.  The initial compromise that led to access
> within the network may have been through malware or some other
> vulnerability, but I do think monitoring on an internal network (encrypted or
> not, through logs or on the wire) is the use case for attack detection that is
> plausible with the proposed approach.

Ok, now it's clear for me. I don't know why I thought I had seen a couple of times these last days people talking about the need of IPS to decrypt traffic going from the enterprise to internet, trying to detect exfiltration of data or connections to a malware C&C, which is not the scope of the draft, and I thought we were starting to veer off-course in the discussion.

As usually happens, I've been looking for those previous messages (not too hard I must admit) and I have been unable to find them, so I probably misunderstood what someone meant...

My bad!

---

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

> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <[email-masked]> wrote:
> 
> On the one hand, the bot would never opt-in for visibility if it’s trying to exfiltrate data…

The presumption is that any legitimate application would opt-in, so the IPS blocks any TLS connection that does not opt in.

---

From: Roland Zink <[email-masked]>
Date: Thu, 15 Mar 2018 19:22:03 +0100

Am 15.03.2018 um 17:58 schrieb Carl Mehner:
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> Yes, they might, however, the best place for malware detection is on 
> the edge (which is out of scope for "in the Datacenter" type 
> connections) and the endpoint, where an agent is able to run that does 
> not need to 'break in' to the TLS session. Yes, the Fenter draft talks 
> about how malware endpoints can be anywhere in the network, and that 
> they can delete logs as a reason to require out of band network 
> decryption. However, if "breaking TLS" becomes an effective malware 
> mitigation means, more malware makers may move to using app-level 
> encryption (as some already have). Therefore, the conclusion we can 
> draw is that malware is not a reasonable reason requiring this 
> enhanced "visibility".
>
I don't think you can make this conclusion when the fact that app-level 
encryption is used can be detected and blocked. However there might be 
ways to hide like steganography.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 15 Mar 2018 21:50:28 +0000

Good point Yoav.

And this positive side effect holds true in the health care and insurance industries as well,  and is not an accident.  It is one of the primary reasons this monitoring is performed.

From: TLS [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Thursday, March 15, 2018 12:58 AM
To: Rich Salz <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Breaking into TLS to protect customers

Hi, Rich.

Yoav

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Darin Pettis <[email-masked]>
Date: Sun, 18 Mar 2018 09:09:12 -0700

Agreed.   I know a lot of good work has gone into TLS 1.3 and having
visibility to the data once it hits the data center seems like a new
capability to the good folks working that have had TLS 1.3 in mind for the
last couple years.   But to enterprises, they have visibility to their data
today and have become dependent on that visibility to utilize security and
troubleshooting tools.

This actually speaks to the fact the there is a different use case for the
Internet vs the data center.  Hopefully we can agree on that point.

On the Internet, data is transitory in nature and the focus of E2E
security.   Conversely, when the enterprise is the actual recipient of the
data, there is an expectation of security and performance of that data.
 If anything happens to that data, then the enterprise is pointed to - so
we need to see the data to run the needed services.  Initially regulated
companies have been pushed to encrypt internally which then in-turn
requires that data must be decrypted for tools and a select group of folks
can provided the required services.

Additionally, bad actors will have the ability to utilize TLS 1.3
decryption for command and control and data exfiltration purposes.
Security services need to see the data to combat that.

Finally, I wanted to make the clear that we utilize the term "visibility"
because it is the correct term for the outcome that is needed - regardless
of the technology solution that enables it.  Not to inflame anyone at all.
I know it's a contentious issue but appreciate everyone's input and
thoughts to come to a solution as pushing this to another technology or WG
isn't going to solve the current problem in time.  Kuddo's to EDCO for
sharing in both directions.

Thanks,
Darin

On Thu, Mar 15, 2018 at 2:50 PM, Ackermann, Michael <[email-masked]>
wrote:

> Good point Yoav.
>
>
>
> And this positive side effect holds true in the health care and insurance
> industries as well,  and is not an accident.  It is one of the primary
> reasons this monitoring is performed.
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Yoav Nir
> *Sent:* Thursday, March 15, 2018 12:58 AM
> *To:* Rich Salz <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Breaking into TLS to protect customers
>
>
>
> Hi, Rich.
>
>
>
> (collateral benefit?). The object is to protect the system integrity and
> the data.
>
>
>
> Yoav
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>

---

From: Eric Mill <[email-masked]>
Date: Sun, 18 Mar 2018 18:20:19 -0400

> Internet vs the data center.  Hopefully we can agree on that point.

We maybe can agree that enterprises feel they have become dependent on
their current set of security and troubleshooting tools, which rely on passive
decryption for visibility. That doesn't mean that that the enterprise is
actually dependent on that current set of tools.

> Security services need to see the data to combat that.

Passive decryption is not necessary to do this. Active
decryption/termination can also accomplish this, where all outbound network
traffic is required to pass through trusted proxies -- an active approach
is necessary anyway to actually stop data from being exfiltrated.
Presumably stopping the data is superior to just being able to see it
leaving later when looking through forensics.

> of the technology solution that enables it.
>

Totally agree, though it's still not obvious why the tools to enable this
don't already exist.

-- Eric

>> You are conflating customers and users. The customer that may be
>> protected by breaking TLS in a bank’s server farm is the bank itself. An
>> IPS system with visibility into the traffic may detect bots that are there
>> to steal data or mine cryptocurrencies or whatever.
>>
>>
>>
>> The information contained in this communication is highly confidential
>> and is intended solely for the use of the individual(s) to whom this

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Matthew Ford <[email-masked]>
Date: Mon, 19 Mar 2018 08:28:55 +0000

Hi Darin,

> On 18 Mar 2018, at 16:09, Darin Pettis <[email-masked]> wrote:
> 
> pushing this to another technology or WG isn't going to solve the current problem in time.

In time for what?

Mat

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 19 Mar 2018 07:32:09 +0000

On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>> I fail to see how the current draft can be used to provide visibility
>> to an IPS system in order to detect bots that are inside the bank…
>> 
> The presumption is that any legitimate application would opt-in, so
> the IPS blocks any TLS connection that does not opt in.

Thanks for clarifying the bigger picture here, Yoav.

So if this technology were deployed on a network where not all parties
are mutually trusting, it would offer network users a choice between
surveillance by the network on the one hand (opt-in) and censorship on
the other (opt-out and be blocked).  Is that right?

Designing mechanism for the Internet that allows/facilitates/encourages
the network operator to force this choice on the user seems problematic.
Why do we want this for a protocol like TLS that is intended to be used
across potentially adversarial networks?

datacenter operators who want access to the cleartext passing through
machines they already control already have mechanisms at their disposal
to do this (whether they can do so at scale safely without exposing
their customers' data to further risks is maybe an open question,
regardless of mechanism).

Mechanisms that increase "visibility" of the cleartext run counter to
the goals of TLS as an end-to-end two-party secure communications
protocol.

Regards,

     --dkg

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 19 Mar 2018 06:53:13 -0400

+1

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

CDT's Annual Dinner, Tech Prom, is March 29, 2018. Don't miss the tech
event of the year!
Reserve a table today.: https://cdt.org/annual-dinner/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Mar 2018 13:23:30 +0000

Hi, Daniel

Inline...

> On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

I see it a little differently. Your computer or my computer, both of which are not configured to opt-in, should not be on such networks. In the corporate world, there could be a production network that enforces this and has access to corporate resources. There will usually also be a “guest” network with unfiltered connectivity, but no access to internal databases. This is where visitors go, but also where employee phones connect.

Of course the government of Elbonia might require all networks to have this feature, and then you’ll have to decide if you want to configure your laptop to opt-in.  I would prefer to stay off-line while I’m in Elbonia in that case.

> across potentially adversarial networks?

This is for hosts using network owned by the same entity that owns the hosts. When such hosts communicate outside this network, it’s for the leg of the connection that is within this network. I don’t see any use for it across an adversarial network.  If you trust it enough to give it your keys, it’s not adversarial.

> regardless of mechanism).

I don’t think these mechanisms are currently available.  That’s a good subject for discussion.  If such mechanisms can be written without extending TLS, that’s obviously better.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 19 Mar 2018 07:20:04 -0700

It's true that breaking open cleartext runs counter to the mission of
end-to-end TLS, but it also seems like operators are going to do it if they
can. Whether by staying on plain RSA, using static-DH, MITM through
installing a private trusted CA, or exporting session secrets, they can
certainly do it.  I worry that we'll lose a good opportunity to improve the
security and transparency of things by turning our nose up at that.

Here's a straw-man suggestion:

Suppose we took on a draft that adds a new optional handshake message. The
message could go immediately before FINISHED, in either direction (or
both), and contain an encrypted version of the soon-to-be-session-key.  For
back-compat: it could be encrypted with RSA, or whatever else the endpoints
want to support. This is basically what STEK encrypted tickets look like
today with TLS1.2 anyway, though usually with symmetric encryption, so it's
not that wild a departure.

Obviously this breaks forward secrecy, and allows passive tapping and
session hi-jacking, but then that's the point. But I think there are some
security advantages too:

1/ By making the functionality part of the handshake transcript, it is
unforgeably evident to both sides that it is happening. The proponents of
this functionality claim that everything is opt-in, but this gives some
cryptographic teeth to it.

2/ clients and browsers could easily consider such sessions insecure by
default. This would mean that adopters would have to deploy configurations
and mechanisms to enable this functionality, similar to - but beyond - how
private root CAs can be inserted.

Wouldn't those be good properties to have? Compared to servers secretly
exporting transcripts or session keys, or just having a private root CA
installed which breaks all sorts of certificate verification
infrastructure?

I think the existence of a "standard" here could also serve to encourage
providers to do things the more transparent way, and create less likelihood
of a mass-market of products that could also be used for more surreptitious
tapping.

On Mon, Mar 19, 2018 at 12:32 AM, Daniel Kahn Gillmor <[email-masked]

-- 
Colm

---

From: R du Toit <[email-masked]>
Date: Mon, 19 Mar 2018 11:50:57 -0400

Commenting purely on the straw-man proposal:

How would passive tools get to the new message if it is sent before the TLS 1.3 server Finished, given that the handshake is already encrypted by that point?

You could send it as plaintext before client Finished, but that changes the properties of resumption_master_secret, and impacts the TLS state machine on the server end, which now has to accept plaintext records after switching to protected handshake records.

--Roelof

From: TLS <[email-masked]> on behalf of Colm MacCárthaigh <[email-masked]>
Date: Monday, March 19, 2018 at 10:21 AM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Breaking into TLS to protect customers

It's true that breaking open cleartext runs counter to the mission of end-to-end TLS, but it also seems like operators are going to do it if they can. Whether by staying on plain RSA, using static-DH, MITM through installing a private trusted CA, or exporting session secrets, they can certainly do it.  I worry that we'll lose a good opportunity to improve the security and transparency of things by turning our nose up at that. 

Suppose we took on a draft that adds a new optional handshake message. The message could go immediately before FINISHED, in either direction (or both), and contain an encrypted version of the soon-to-be-session-key.  For back-compat: it could be encrypted with RSA, or whatever else the endpoints want to support. This is basically what STEK encrypted tickets look like today with TLS1.2 anyway, though usually with symmetric encryption, so it's not that wild a departure. 

Obviously this breaks forward secrecy, and allows passive tapping and session hi-jacking, but then that's the point. But I think there are some security advantages too: 

1/ By making the functionality part of the handshake transcript, it is unforgeably evident to both sides that it is happening. The proponents of this functionality claim that everything is opt-in, but this gives some cryptographic teeth to it. 

2/ clients and browsers could easily consider such sessions insecure by default. This would mean that adopters would have to deploy configurations and mechanisms to enable this functionality, similar to - but beyond - how private root CAs can be inserted. 

Wouldn't those be good properties to have? Compared to servers secretly exporting transcripts or session keys, or just having a private root CA installed which breaks all sorts of certificate verification infrastructure? 

I think the existence of a "standard" here could also serve to encourage providers to do things the more transparent way, and create less likelihood of a mass-market of products that could also be used for more surreptitious tapping. 

On Mon, Mar 19, 2018 at 12:32 AM, Daniel Kahn Gillmor <[email-masked]> wrote:

Regards,

     --dkg

 

-- 

Colm

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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 19 Mar 2018 12:22:48 -0400

> private root CAs can be inserted.

I thought the use case was that this was not for clients and browsers, but
for server<->server interactions.

> installed which breaks all sorts of certificate verification

A number of platforms are moving away from the ability to install private
root CAs. Platforms such as Android, ChromeOS, and iOS are three examples
of modern 'consumer' platforms that restrict or prevent such ability. On
the consumer electronics space, you have a variety of TLS-using clients
without such capability at all.

In these cases, servers secretly exporting transcripts achieves the
properties desired, but the other solutions would preclude such devices.
For the use cases described, could you clarify why this would be
undesirable?

> of a mass-market of products that could also be used for more surreptitious

It's difficult to speculate here about the potential impact, but isn't
another possibility that it would legitimize a mass-market of such
products, particularly if such capabilities were introduced into clients
and browsers? You could, for example, see governments encouraging and/or
requiring the use of such protocols, which otherwise would not be
technically possible on the aforementioned platforms.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Mar 2018 11:29:57 -0500

> This is for hosts using network owned by the same entity that owns the hosts. When such hosts communicate outside this network, it’s for the leg of the connection that is within this network. I don…

If the network is actually trusted, then there is no need for
transport encryption at all.  So, whether due to real risk or risk
perceived by compliance regimes, the network must be considered to
potentially be adversarial.  Perhaps this could be rephrased as "the
intended network is operated by a trusted entity", but is the
network authenticated?  With an attacker potentially in play, is the
network compromised?  It's hardly a home run to blithely claim that
the network is trusted, without further exposition.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Mar 2018 11:38:43 -0500

> for server<->server interactions.

This is an important question the answer to which remains unclear,
to me.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Mar 2018 16:52:45 +0000

*   It's difficult to speculate here about the potential impact, but isn't another possibility that it would legitimize a mass-market of such products, particularly if such capabilities were introduced into clients and browsers?

That is definitely a goal. The people who are in favor of this, want commoditized offerings so that they can get it more cheaply, standardized, and with much less effort and expense on their part. Last time, I pointed out that this clear-text signaling could be used as additional leverage by captive portals (my example was passengers on a plane with inflight Wifi).

If I were really twisted, I could imagine ISP’s (or operators) requiring this to put customers in the “high speed lane” or traverse a Big Firewall. Of course, purely for efficiency.

---

From: Eric Mill <[email-masked]>
Date: Mon, 19 Mar 2018 17:59:10 -0400

On Mon, Mar 19, 2018 at 9:23 AM, Yoav Nir <[email-masked]> wrote:
[snip]

> I see it a little differently. Your computer or my computer, both of which
> are not configured to opt-in, should not be on such networks. In the
> corporate world, there could be a production network that enforces this and
> has access to corporate resources. There will usually also be a “guest”
> network with unfiltered connectivity, but no access to internal databases.
> This is where visitors go, but also where employee phones connect.
>
> Of course the government of Elbonia might require all networks to have
> this feature, and then you’ll have to decide if you want to configure your
> laptop to opt-in.  I would prefer to stay off-line while I’m in Elbonia in
> that case.
>

That seems like notably less of an option for the citizens of Elbonia.

-- Eric

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Mar 2018 05:03:45 -0500

[Apparently this was stuck in my 'drafts' folder; sorry if it has
since become stale...]

> Here's a straw-man suggestion:

The straw man is indeed made of straw, but some observations
regardless...

> cryptographic teeth to it.

It's not entirely clear that this scheme is forced into the
handshake, e.g., if the server collaborates with the network to drop
the new message, the server will not include it in the transcript
and the client will never see it, so the client would not
necessarily know about it.

But there are other ways to modify the key schedule that would
require both parties' consent (and potentially preconfiguration).
The most obvious ones would not technically be TLS anymore, but
would be very close; one could do this sort of thing with or without
a network-visible signal that it is in use, provided that both
endpoints agree that it is to be used.  For server-to-server, this
may be tolerable.

> of a mass-market of products that could also be used for more surreptitious

Right, the claim has been made that a standard is useful so that
multiple vendors' products can interoperate within a single
enterprise.

-Ben