Re: [TLS] Breaking into TLS to protect customers

[Ryan Sleevi <[e-mail]>]

On Mon, Mar 19, 2018 at 10:20 AM, Colm MacCárthaigh <[e-mail]>
wrote:

> 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.
>

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


> 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?
>

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?


> 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.
>

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.