This repository is a place to collect together arguments for not breaking TLS.
At some point it may be worth turning this into an Internet-draft to save us all time for when the next crappy break-TLS proposal comes along.
PRs that add to (really, record) those arguments are welcome, especially if they identify problems with specific proposals to break TLS.
In this section we call out some generic issues that all cause all "break-TLS" proposals to fail.
-
As with most of these break-TLS attempts, the proponents have apparently only analysed the deployments about which they care, and ignore all other uses of TLS. There are many other 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. Screwing around with such a protocol without due dilligence is utterly unwise.
-
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 they are misguided. 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 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 "break-TLS" proposal, no matter what motivations are set out by proponents. (And again, that says nothing at all about proponents motivations, it's just a thing that we have to consider regardless.)
This is one of the current proposals for breaking TLS. It fails in the following ways:
-
The TLS working group charter dated 2017-03-30 calls for improving the security of TLS, and this proposal involves leaking private key material and hence falls outside the charter.
-
This draft is targeted as being an IETF standards track document but is a wiretapping scheme that meets the definition in RFC2804 and therefore cannot be a standards-track work item in the IETF.
-
Some have argued that even if this cannot be an IETF standards track specification, it should still be developed in the IETF. That also goes against RFC2804, which calls for documentation and not development, of deployed wiretapping schemes. Documenting the wiretapping schemes that exist is a good thing. Developing new ones is a bad thing, for all the reasons set out explicitly in RFC2804. As a speculative new wiretapping design, this draft should not be an IETF specification of any kind, so long as RFC2804 has not been obsoleted, and yet the authors here are making no attempt to obsolete 2804, and are thus attempting an end-run around IETF processes.
-
This draft aims to provide wiretapping only "within" enterprise networks, but there is no way (and cannot be a way) to constrain the use of this scheme to such networks. Figure 3 of the draft clearly describes a generic wiretapping architecture for TLS that could (and would) be used in many other circumstances that the authors have apparently not envisaged.
-
This draft tries to standardise broken crypto - forward secrecy is a goal of cryptographic protocols and this draft deliberately aims to not provide forward secrecy and indeed to break forward secrecy without the TLS client being aware of that.
-
The argument has been made that it would be better to scrutinise proposals such as this openly in the IETF instead of having individual vendors develop their own bad-crypto implementations. As a counter to that, while scrutiny is good for good crypto, the overall ecosystem will be harmed by wide-spread use of the same bad-crypto, so therefore in the case of bad-crypto proposals such as this, it is better for us all that there is not a single standard.
-
For the enterprise uses claimed to justify this, there is no need for Internet-scale interoperability as the enterprise network is by-definition under a single entity's control. (And if they cannot control their network, then adding broken crypto seems even more unwise.)
-
This draft doesn't allow TLS clients and applications above or behind the TLS server to know that wiretapping is occurring.
-
Ossification: this draft would introduce new ways of ossifying TLS, for example, the so-called "TLS decrypter" would have to be able to handle all updated ciphersuites before those could be used by bona-fide TLS clients and servers. We have seen that non-updated PKCS#1.5 crypto hardware has caused problems with updating the crypto in TLS for decades now, and this would cause similar problems.
-
This proposal entirely suits what governments doing pervasive monitoring would need in an API. The IETF has documented its consensus that Pervasive Monitoring is an Attack in RFC 7258, and this API would assist with such attacks. In case this seems somewhat abstract, we have evidence of exactly this kind of key exfiltration API in IPsec, as documented by Wouters and Der Spiegel.
-
We also have a documented case where a law enforcement agency have attempted to coerce a mail service provider (Lavabit to providing TLS secret key materials. Developing an API such as envisaged in this draft would encourage such law enforcement attempts at key recovery in many countries.
Some of the authors have denied that this is a wiretapping propospal, based on not matching the definitions in RFC2804. However, with SMTP/TLS and with any intermediate MTA, this clearly allows that intermediate MTA to renege and leak their private values and hence senders and recipients will not get the confidentiality they expect. Note that SMTP/TLS is almost ubiquituous today and that 2-TLS session setups are common, e.g. if the intermediary MTA does AV scanning.
For example, about mcTLS, if you have the energy to consider that nonsense.