tinfoil: TLS Is Not For Obligatory (Or Ostensibly Optional) Interception, Luckily

20180319 update - the TLS WG discussed version -01 of https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01 and there was no consensus to adopt that, so that proposal may now be dead.

20171009 update, I've started to document the failings of the latest proposal we're forced to deal with. Believe it or not, I did do a pass to tone down the language already, but am happy to do more of that, if people think that'll help the discussion. Not that this discussion can be anything but horrendous:-(

20171019 - just noting a few points that were raised in the initial TLS WG list discussion of draft-rehired

This repository is a place to collect together arguments for not breaking TLS. By "breaking TLS" I mean significantly weakening the protocol, or implementations or deployments of the protocol, so that the security claims made in the protocol specification can no longer be credibly maintained.

Note that one does not need to accept all arguments in order to properly conclude that breaking TLS is a bad plan or that some specific break-TLS proposal is a bad plan. One killer argument per proposal should be enough, but it's useful to collect more than that anyway.

At some point, if the TLS WG want to, it may be worth turning this into an Internet-draft to save us all time for when the next break-TLS proposal comes along. In the meantime, reading this as if it text were in a -00 draft is probably roughly correct if you're familiar with IETF stuff. (IOW, this isn't perfect text and that's ok:-)

PRs that improve or add to or just record those arguments are welcome, especially if they identify problems with specific proposals to break TLS.

Scheme-independent Points

In this section I call out some generic issues that affect all "break-TLS" proposals:

1. With all break-TLS attempts so far, the proponents only seem to have analysed the deployments or use-cases about which they care. As far as one can see they appear to generally ignore other uses of TLS. But there are many many uses of TLS, for example the TLS1.2 RFC is currently (20170711) referenced by 434 other IETF specifications, and is cited by 3,281 publications in Google Scholar. Accepting any proposal that might weaken such an important security protocol without due diligence is utterly unwise. And it is hard to see how anyone could really do that due diligence given the breadth of use of TLS today - both in openly specified foo/TLS applications but also in the presumably larger number of not publicly documented applications using TLS.

2. Note that I make no allegations about the bona-fides of any of the proponents of the "break-TLS" schemes. I know and respect some of them, but consider them misguided in contributing to proposals to break TLS. However, we cannot ignore the fact that some governments are very keen to weaken Internet security and privacy and have allocated significant budgets for that. BULLRUN for example is reported to have involved wasting/spending US$250M/yr on this. It is inevitable that some of that money ends up being spent/wasted on schemes to break or weaken TLS. The consequence of that is that it is entirely proper to consider the Pervasive Monitoring aspects of any proposal as part of our threat model no matter what motivations are set out by proponents. (And again, considering this says nothing at all proponents' motivations, it's just a thing that we have to consider regardless.)

3. TLS is already hard, as we have seen from two decades of exploits against implementations and, occasionally, against the protocol itself. The added complexity of any "break TLS" proposal makes that situation worse, and logically must do so. But we have more than argument to go on here - there is evidence for this from peer-reviewed academic studies and examination of TLS interception implementations, for example Durumeric et al. found that "that nearly all [interception proxies] reduce connection security and many introduce severe vulnerabilities" whilst de Carnavalet et al. performed a "systematic analysis uncovered that several of these tools severely affect TLS security on their host machines." So, where there is evidence publicly available, it seems to indicate that additional complexity (via proxies or other methods of breaking TLS) reduces security. To my knowledge, none of the proposed "break TLS" schemes has ever offered evidence that they would lead to an overall improvement in security.

4. In many cases like this people also argue that even if breaking TLS is undesirable, it's better to do that undesirable thing openly inside the IETF as it would happen elsewhere in any case and perhaps be done worse. Without specific evidence that organisation foo is about to take action bar, that argument is impossible to judge, so is at best neutral. When there is specific evidence of something relevant being done elsewhere, then the IAB and IESG have liaison mechanisms that can be used for the purpose for which they were designed. IOW, "if we don't, they will" is not a good argument that the IETF should do any particular thing at all. In the author's experience, this argument is commonly associated with proponents of proposals that might be fairly described as being engaged in forum shopping. In the case of "break TLS" proposals, one could argue (and I would) that the reason TLS is widely used is, in significant part, because TLS is not broken.

5. <id ="iabst" name="iabst"/>In 2014, the Internet Architecture Board issued a statement to the effect that "Internet depended on users having confidence that the network would protect their private information" and that we should "make encryption the norm for Internet traffic." All proposals to break or weaken TLS go against that sound advice (not repeated here because we'd end up repeating almost all of it). The IAB statement recognises that increasingly widespread use of TLS causes issues for network operations, but no response that amounts to attempting to break TLS so far presented can be justified due to the huge potential cost and impact of breaking TLS.

6. Most or all approaches to breaking TLS seem to involve changing TLS from a two-party protocol (ignoring CAs for now) into a multi-party protocol, but one that mimics the behavior of TLS in order to have a chance to get deployed on the Internet. A multi-party transport security protocol however would require either a substantially different API or to move up the stack to solve whatever problem one is facing.

7. Some people argue that 20 years (or so) ago the IETF was wrong to have ignored the reality of NAT deployments, and draw a comparison with breaking TLS, particularly in enterprise gateways. They draw the erroneous conclusion that the IETF should therefore standardise ways to break TLS, as a way of dealing with what is the sad reality for some networks, where TLS is intercepted. Firstly, by itself that's not good logic, as it would mean that the IETF should standardise anything that is deployed without exercising any judgement. But most people making the argument probably don't really mean that and implicitly think that some level of TLS interception is unavoidable. But regardless of what one thinks about NAT, the conclusion that we ought therefore break TLS remains erroneous - recognising the existence of NAT would not have directly damaged networks that do not use NAT, whereas breaking TLS causes breakage and damages trust for all applications using TLS, for all time - the impact here would be far broader than just the networks already suffering TLS interception. So the equivalent argument really would be: should the IETF have entirely given up on the end-to-end argument because of NAT deployments or not? And the answer to that is "no," just as the answer when asked to standardise breaking TLS is "no." The bottom line is that the "it's just like NAT, the network suffered because we ignored NAT, so we should break TLS" argument is fallacious.

8. Ben Kaduk raised a general issue that is a problem whether or not break-TLS proposals try to be an "opt-in" by making themselves visible to TLS clients: if they do not, then they fail to be transparent (as in draft-green ), but if they do make themselves visible in a way that a network intermediary can see, then "once a visible ClientHello extension is needed to enable wiretapping, certain parties (e.g., national border firewalls) would reject/drop all ClientHellos not containing that extension, thereby extorting all clients into "opting in" to the wiretapping and effectively rendering the "opt-in" requirement useless for those clients." And it seems hard to propose an opt-in scheme where the opting-in or not is not detectable by an on-path intermediary.

9. Even though the stated goal of these proposals is to allow monitoring of the connection contents, exposing the session keys