On Mon, Mar 19, 2018 at 10:20 AM, Colm MacCárthaigh <c...@allcosts.net> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
