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 add to (really, record) those arguments are welcome, especially if they identify problems with specific proposals to break TLS.

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 dilligence is utterly unwise. And it is hard to see how anyone could really do that due dilligence 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 implmentations, 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 actionn 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 mechaisms 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 assoociated 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. 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 jusified 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.

This is the current (July 2017) proposal for breaking TLS. It fails in the following ways:

1. 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 clearly falls outside the charter.

2. Stephen Checkoway raised a different charter issue: "There are essentially two separate proposals in the I-D. Section 5 proposes a slight change to TLS that results in no changes on the wire and, as far as I can tell, is already allowed (but should probably be discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to do. Sections 6 and 7 propose a new protocol for distributing key pairs. The use case is TLS, but it isn't specific to TLS and doesn't interact with TLS (outside of using TLS for HTTPS). As such, I believe it's outside the WG's charter."

3. TLS1.3 (and DTLS1.3) are still not finished and any work within the IETF on this draft will put those efforts at risk. For example, the abstract of the latest TLS1.3 draft says that TLS is "designed to prevent eavesdropping" - changes to that and possibly many other claims would be needed if the TLS working group adopted this, or any similar, draft. Those changes would not all be editorial and would likely be time-consuming.

4. As a result of the discussion of this draft, Christian Huitema has proposed a pull request for TLS1.3 to encourage implementers to effectively make the idea in this draft harder to deploy, by documenting the core static DH value idea as an attack against which TLS clients ought attempt to defend themselves. Adopting work on static DH values would therefore have the effect of forcing the working group to work against itself, further delaying and putting TLS1.3 at risk.

5. TLS1.3 has undergone significant academic and other analyses, (including two academic workshops, TRON in 2016, and TLS-DIV in 2017), none of which (to my knowledge) envisaged the use of static DH values, nor of centrally generated DH values being "pushed" to many TLS servers. Similarly, work on the TLS application layer PDU protection didn't envisge re-use of DH values in possibly many TLS sessions. Adoption of any work in this space could require re-doing some of the analysis work, possibly delaying TLS1.3 or (worse) resulting in new problems being found after widespread deployment. Given that this draft would create new active and passive attack possibilities, such new analysis work would seem to be required, especially if proprietary extensions to the proposed "TSK" protocol affect the cryptogrphy used in TLS sessions.

   • The work done by academic analyses of TLS1.3 has been valuable in terms of improving the quality of the IETF's output. Radical changes to TLS1.3 at this point will likely disincent researchers from contributing as a part of the process in future as they may perceive the IETF to be moving the goalposts at the last minute, indicating that IETF participants do not value their inputs. (I admit that is speculative, but it's based on some previous discussions on the WG list - it'd be good to get feedback from researchers to check.)

6. Kenny Paterson (private communication, quoted with permission) notes that history has shown that static DH in TLS (and elsewhere) is not "implementation robust" - another relevant attack is this one which is quite spectacular.

7. There could be similar problems caused for the QUIC protocol development work, as that relies upon TLS1.3 and has similar design elements that could be perturbed if static DH private values were used. And QUIC has recently been proposed as a substrate for 5G efforts in another SDO with fairly aggressive timelines, so delays in developing QUIC caused by breaking TLS could have significant effects elsewhere.

8. This draft aims/claims to enable key-leaking/wiretapping only "within" enterprise networks, but there is no way (and cannot be a way) to constrain the use of this scheme to such (parts of) networks. Figure 3 of the draft (reproduced below) clearly describes a generic key-leaking/wiretapping architecture for TLS that could (and would) be used in many other circumstances that the authors have apparently not envisaged.

   • As pointed out on the list (e.g. by Yoav Nir and others), if there was a standard for this scheme, code for that would leak into being used on the public Internet via the normal implementations that are used both within and outside pretty much all networks.

9. We also have a documented case where a law enforcement agency has attempted to coerce a mail service provider called Lavabit into providing TLS private key materials. Developing an API such as envisaged in this draft would encourage such law enforcement and other agency attempts at key recovery in many countries. So the unintended uses for this are as real as the intended ones. (An aspect that is ignored by the draft and it's proponents.)

10. This draft is targeted as being an IETF standards track document but is a wiretapping scheme (or enables wiretapping) that meets the definition in RFC2804 and therefore cannot be a standards-track work item in the IETF.

    • Some may argue that even if this cannot be an IETF standards track specification, it should still be further developed by the IETF. IMO, (though this is guessing to an extent) 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 RFC2804, and are thus attempting an end-run around IETF processes.

    • To my knowledge, all wiretapping schemes docuemted in RFC so far have been in the independent stream (hence not IETF docuemts) or perhaps pre-date RFC streams.

    • See below for more on this as a wiretapping proposal.

11. 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. In that case, a collector has ciphertext packets and calls a function (passing in initial packets) to get a key for packet decryption. An implementation of such a function could clearly benefit from the GET DH value API defined in this document.

12. 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. BCP200 (which was promoted to BCP in 2015, and so is very recent) specifically argues against such schemes:

    • "Escrow mechanisms inevitably weaken the security of the overall cryptographic system, by creating new points of vulnerability that can and will be attacked."

    • "KEYS SHOULD NOT BE REVEALABLE The security of a modern cryptosystem rests entirely on the secrecy of the keys. Accordingly, it is a major principle of system design that to the extent possible, secret keys should never leave their user's secure environment. Key escrow implies that keys must be disclosed in some fashion, a flat-out contradiction of this principle. Any such disclosure weakens the total security of the system."

    • "Even if escrowed encryption schemes are used, there is nothing to prevent someone from using another encryption scheme first. Certainly, any serious malefactors would do this; the outer encryption layer, which would use an escrowed scheme, would be used to divert suspicion."

    • "A major threat to users of cryptographic systems is the theft of long-term keys (perhaps by a hacker), either before or after a sensitive conversation. To counter this threat, schemes with "perfect forward secrecy" are often employed. If PFS is used, the attacker must be in control of the machine during the actual conversation. But PFS is generally incompatible with schemes involving escrow of private keys. (This is an oversimplification, but a full analysis would be too lengthy for this document.)"

    • Note that while the concept of key escrow that was being promulgated in the mid 1990's is not identical to that being proposed here, the same vulnerabilities are created once one leaks private key materials, especially via a "standard" interface.

13. Aside from the process/BCP perspective on "bad crypto" Nick Sullivan pointed out issues with the specific proposal: "Static Diffie-Hellman is a cryptographically problematic construction. Not only was it found to be fragile to implement in the prime field variant (LogJam), the Elliptic Curve variant has recently been identified as troublesome as well (see recent JWE vulnerability and CVE-2017-8932). Furthermore, many post-quantum key exchange mechanisms cannot be secured with repeated key shares (SIDH is one example). Encouraging (or worse, standardizing) the repeated use of a key share seems risky and shortsighted. "

14. 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 bad-crypto standard.

15. Ironically, the first author of draft-green is also a co-author of keys under doormats. While that latter report mainly considers government mandated back-doors, it does also correctly point out that: "Communications technologies designed to comply with government requirements for backdoors for legal access have turned out to be insecure. For ten months in 2004 and 2005, 100 senior members of the Greek government (including the Prime Minister, the head of the Ministry of National Defense and the head of the Ministry of Justice) were wiretapped by unknown parties through lawful access built into a telephone switch owned by Vodafone Greece [19]. In 2010 an IBM researcher observed that a Cisco architecture for enabling lawful interception in IP networks was insecure. 2 This architecture had been public for several years, and insecure versions had been implemented by several carriers in Europe [20]. And when the NSA examined telephone switches built to comply with government-mandated access for wiretapping, it discovered security problems with all the switches submitted for testing[21]. Embedding exceptional access requirements into communications technology will ensure even more such problems, putting not only private-sector systems, but government ones, at risk." The draft being discussed here is just enabling another form of exceptional access, despite being designed for enterprise-access and not for government access, so the fine points quoted above are as applicable.

    • One of the reactions to excessive government data retention has been to suggest requiring corporations to store the relevant (or all!) data and to then make that information available to government as needed. The API defined here could assist that kind of privatisation of government pervasive monitoring as a kind of federated government backdoor, if governments mandated use of this scheme.

16. A suggestion was made on the TLS list that the deployment of this scheme be made part of a "website's terms of service." Hiding the fact that one is breaking TLS in legalese seems like a terrible idea to this user of the web.

17. Whether or not use of this scheme is visible to the Internet has a number of consequences, all of which appear to be bad outcomes.

    • This scheme doesn't allow normal TLS clients (without visibility of DH re-use) and applications above or behind the TLS server to detect that wiretapping is occurring. That means we cannot know if their threat models match reality or not. That is essentially a layering issue - this, and all, "break TLS" proposals change the semantics of TLS without letting the applications and prtoocols that depend on TLS know that that change has happened.

    • To this reader, it is not clear whether or not deployments of the -01 draft, would be detectable or not, from the Internet. (Detection could be visible to an "ordinary" client or might require a zmap-like survey.) It is clear though that -01 has enough extension points so that an undetectable version of this scheme would be easy to invent and deploy.

      • A strawman undetectable version: change the CMS wrapper to indicate that the value contained therein is the RNG seed for a specific algorithm for generating a sequence of DH private values. Other than e.g. one new OID, that could look precisely the same as the current scheme. That should work fine for any situation where the TLS server and the TLS decrypter have similar CPU capabilities for the relevant traffic, which is probably many cases.

      • The upshot is: we cannot assume that this scheme will be detectable.

    • If use of this scheme is detectable,and if it is not widely used, it will likely fall out of use and end up worthless as the reputational cost of being shown to be a deployment of this would be high. ("Hey, all my cookies are leaked when I talk to example.com!") That means effort to scrutinise this in the IETF would be wasted.

    • If this is detectable and somehow is widely deployed, the impact of exploits of the inevitable vulnerabilities would be gigantic as many many TLS servers would offer an API to extract their DH private values. ("Hey, what domains TLS cleartext would you like to buy?")

    • If the scheme is initially detectable, and not very widely deployed (highly likely at least at first), then deployments will make modifications to the scheme to avoid detection. Such proprietary modifications mean that all effort to "improve" or "scrutinise" this scheme would certainly be wasted. Proprietary modifications could also significantly weaken security.

18. Developing this interface within the IETF would arguably increase the probability of "worse solutions" being deployed as those would be easier to integrate thanks to the existence of the "GET private key" API that TLS servers might then offer. An argument for this draft was offered that standardising it would avoid such "worse solutions" - I see no evidence offered and claim (with the same evidence;-) that the opposite would eventuate.

19. This scheme enables active attacks - once the DH private values are known, then all session keys are known and seemingly valid packets can be injected into ongoing sessions. The abstract of the -01 draft is extermely misleading in claiming that it is for "passive monitoring." No mention is made in the draft of the active attacks it enables.

20. If this scheme were widespread, it would be "accidentally" deployed in places for which it was not intended. (See also RFC2804.) The result could be active attacks on e.g. widely downloaded web resources enabling active attacks on browsers. I would expect another decade of academic publications and real exploits on TLS to result.

21. Applications built on TLS, e.g. the Web, would need to revise their security models to take into account this scheme, as it changes the threat model on which they have been built.

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

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

24. Brian Carpenter points out (private communication, quoted with permission) that "server load balancing and TLS load balancing don't mix well. (See RFC7098 for more.) In fact, there's no practical alternative for large server farms except TLS proxying in front of the servers. At a quick glance it seems to me that draft-green doesn't separate this issue from the rest. But server farms have no choice about solving that problem, or the intrusion/DOS detection problem, but they do have a choice about monitoring as such. Separating the operational requirements from the political requirements might be a good first step."

While I'm reluctant to comment on the details of a bad design, there are a couple of things to point out:

1. The fact that this draft both breaks and depends upon TLS (in it's use of HTTP/TLS via RFC2818) means that this drafts enables "meta-attacks" where another party can eavesdrop on the connections between the various TLS-breaking components defined here, if (as would seem likely to me) the OPTIONAL additional CMS protection is not used. Similarly, such a meta-attacker could likely inject chosen DH values into a deployment.

2. Section 7.2 defines a key request interface, but defines no authorisation scheme, no HTTP authentiction, and requires no additional CMS protection. This creates an excellent target to attempt to find when one has breached some network. That is an excellent example of the kind of additional vulnerability created by these schemes called out in BCP200 and RFC2804. There is ample recent evidence Wannacry that many enterprises are not capable of shutting down or controlling such interfaces that either ought not be offered or need to be protected.

3. Richard Barnes points out that there may be "unstated requirements here to support for resumption (without having to find the previous session) and probably 0xRTT, and those modes use in a shared secret in addition to the DH secret. So you would need to exfiltrate the PSK as well." If correct, that would seem to indicate that this proposal is broken.

4. The use of CMS means that there are already a vast array of possible (even deployment-speciic) extension points in this protocol. That means that it is not possible to have any confidence that what would be designed is what would be deployed. In fact, given the detectability issues above, it seems very likely that non-deection (meaning non-compliance with the putative RFC) will be a goal for implementers.

IMO none of the above ought not be fixed by IETF participants collectively.

Some IETF TLS WG list participants have denied that this is a wiretapping propospal, based on it somehow not matching the definitions in RFC2804. Firstly, that is far too lawyerly and IMO being overly pedantic with the 2804 definitions. If one looks at Figure 3 in the draft, it very clearly matches any intuitive definition of (an API for) a wiretapping technology. The "TLS decrypter" can be anywhere on the Internet, so long as it has access to the key-leaking API. If some local government coerced some local popular web site into implementing this scheme so that the local government has access to the content of any TLS session with that web site, then I think it'd be insane to not consider that a wiretap on the web site in question.

                    --------------       -----------------
                    | TLS server |-------|  key manager  |
                    --------------       -----------------
                           |                     |
                           |                     |
                           |                     |
                           |             -----------------
                           |------------>| TLS decrypter |
                           |             -----------------
                           |
                           |
                    --------------
                    | TLS client |
                    --------------


                     Figure 3: TSK protocol components
(copied from https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01)

However, we can also easily see how the 2804 definitions are still met, even taking a lawyerly approach...

1. With SMTP/TLS and with any intermediate MTA, (so 3 MTAs on the path) 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. In this case, the relevant parties to the communication (for the RFC2804 definition) are the mail senders and receivers and the AV scanning MTA is the third party that enables wiretapping, just as a telco (with whom the caller or callee presumably has a contract) is the third party in traditional wiretaps.

   • In case of doubts about the scale of SMTP/TLS deployment, see Google's saferemail statistics which shows nearly 90% of mails outbound from gmail.com being encrypted with TLS now. In many mail deployments there will be an added hop e.g. for anti-spam (we do that here in TCD/tcd.ie) to an outside party (in our case outlook.com). (On days when we get enough inbound mail from gmail to be visible in their published DB;-) 100% of mails from gmail.com to tcd.ie are sent via TLS to a host below outlook.com for AV scanning and then on to the TCD MTA, also using TLS. That's perhaps some 10's of thousands of mails per day for the 3,000 staff and 20,000 students in TCD. I'd guess outlook have thousands of customers, so if this draft were deployed in that AV scanning MTA infrastructure, that could put at risk the confidentiality of tens to hundreds of millions of emails per day. So, while less than 100% of mail is encrypted with TLS on all hops, much is. As pointed out on the TLS list, the UTA working group are also developing MTA-STS to try improve that situation, so any argument that mail senders and receivers do not expect confidentiality is sadly outdated.

+-----------+  +--------------+      +----------+     +---------+  +-------------+
|mail sender+--+Submit serveer+--+---+AV scanner+-----+Recip MTA+--+mail receiver|
+-----------+  +--------------+  |   +-----+----+     +---------+  +-------------+
                                 |         |
                                 |         |
                                 |         |
                  -----------------       ----------------
                  | TLS decrypter |-------| key manager  |
                  -----------------       ----------------

                Figure: SMTP/TLS wiretapping setup using 
    https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

1. As another example, consider (esp. vanity domain) web sites where the domain holder doesn't have shell access to the machine that hosts the web site. If the hoster in that case turns on this interface and provides private DH values to someone who has access to the ciphertext TLS packets, then that is clearly wiretapping. That is especially clear if e.g. to people are using such a web site to communicate with one another via some wordpress plug-in. In this scenario the two people who are using some wordpress plugin to communicate are the first and second parties and the hoster is the third party, in the role of the telco in a traditional wiretap.

   • And again, this is a real scenario: wordpress.com has millions of such users, as do many many other hosted sites where those communicating do not have access to a shell or to the TLS server configuration.

+--------------+       +---------------+        +--------------+
|blog commenter+---+---+Hosted Web Site|----+---+blog commenter|
+--------------+   |   +-------+-------+    |   +--------------+
                   |           |            |
                   |           |            |
                   |    -------+--------    |
                   |    | key manager  |    |
                   |    ----------------    |
                   |           |            |
                   |           |            |
                   |   --------+--------    |
                   +---+ TLS decrypter +----+
                       -----------------

                Figure: Hosted web site wiretapping setup using 
    https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01

It does not matter that in these cases the third party (AV scanner or hoster) has access to the cleartext but does not supply that to the consumer of the wiretap - whether the wiretap is based on runtime or later decryption of captured packets, or on playing back physical tapes of a conversation, or on consuming a live feed from the telco-equivalent is immaterial - the end result is that the first and second parties communications are being wiretapped according to the definitions in RFC2804.

Feel free to add analyses of older/other break-TLS here or even just links to drafts/papers. For now, I'll just note a few that'd deserve coverage if the TLS WG think documenting those would be useful.

From the abstract: "This paper presents TLS–Rotate and Release (TLS-RaR), a system that allows device owners (e.g., consumers, security researchers, and consumer watchdogs) to authorize devices, called auditors, to decrypt and verify recent TLS traffic without compromising future traffic."

Analysis TBD.

This was a sigcomm publication (sigcomm went down in my estimation for accepting that) assuming that it makes sense for the random IP address (of a middlebox) to be somehow authorised by the endpoints in a TLS sesssion to join in as a 3rd party in a TLS session.

These drafts were proposed during the development of http/2.

• In 2014: draft-loreto-httpbis-trusted-proxy20-01
• In 2013: draft-vidya-httpbis-explicit-proxy-ps-00
• In 2012: draft-rpeon-httpbis-exproxy-00

I've forgotten what happened with that one, need to go look back @ list.