Re: [TLS] Breaking into TLS to protect customers

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 <tls-bounces@ietf.org> on behalf of Colm MacCárthaigh <colm@allcosts.net>
Date: Monday, March 19, 2018 at 10:21 AM
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: "tls@ietf.org" <tls@ietf.org>
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. 

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 <dkg@fifthhorseman.net> wrote:

On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <ilarra@s21sec.com> 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…
>>
>> 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.

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

-- 

Colm

_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 