├── LICENSE
└── README.md
/LICENSE:
--------------------------------------------------------------------------------
1 | BSD 2-Clause License
2 |
3 | Copyright (c) 2017, sftcd
4 | All rights reserved.
5 |
6 | Redistribution and use in source and binary forms, with or without
7 | modification, are permitted provided that the following conditions are met:
8 |
9 | * Redistributions of source code must retain the above copyright notice, this
10 | list of conditions and the following disclaimer.
11 |
12 | * Redistributions in binary form must reproduce the above copyright notice,
13 | this list of conditions and the following disclaimer in the documentation
14 | and/or other materials provided with the distribution.
15 |
16 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
17 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
19 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
20 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
22 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
23 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
24 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
25 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
26 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # tinfoil: TLS Is Not For Obligatory (Or Ostensibly Optional) Interception, Luckily
2 |
3 | *20180319 update - the TLS WG discussed version -01
4 | of [https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01](https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01)
5 | and there was no consensus to adopt that, so that proposal may now be dead.*
6 |
7 | *20171009 update, I've started to document the failings of the [latest](#latest)
8 | proposal we're forced to deal with. Believe it or not, I did do a pass to tone down the
9 | language already, but am happy to do more of that, if people think that'll
10 | help the discussion. Not that this discussion can be anything but horrendous:-(*
11 |
12 | *20171019 - just noting a few points that were raised in the initial TLS WG
13 | [list discussion](https://www.ietf.org/mail-archive/web/tls/current/msg24492.html)
14 | of [draft-rehired](https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)*
15 |
16 | This repository is a place to collect together arguments for not breaking TLS.
17 | By "breaking TLS" I mean significantly weakening the protocol, or
18 | implementations or deployments of the protocol, so that the security claims
19 | made in the protocol specification can no longer be credibly maintained.
20 |
21 | Note that one does not need to accept all arguments in order to properly
22 | conclude that breaking TLS is a bad plan or that some specific break-TLS
23 | proposal is a bad plan. One killer argument per proposal should be enough, but
24 | it's useful to collect more than that anyway.
25 |
26 | At some point, if the TLS WG want to, it
27 | [may be worth turning this into an Internet-draft](https://www.ietf.org/mail-archive/web/tls/current/msg23909.html)
28 | to save us all time for when the next break-TLS proposal comes along.
29 | In the meantime, reading this as if it text were in a -00 draft is
30 | probably roughly correct if you're familiar with IETF stuff. (IOW,
31 | this isn't perfect text and that's ok:-)
32 |
33 | PRs that improve or add to or just record those arguments are welcome, especially if
34 | they identify problems with specific proposals to break TLS.
35 |
36 | ## Scheme-independent Points
37 |
38 | In this section I call out some generic issues that affect all "break-TLS"
39 | proposals:
40 |
41 | 1. With all break-TLS attempts so far, the proponents only seem to have analysed
42 | the deployments or use-cases about which they care. As far as one can see
43 | they appear to generally ignore other uses of TLS. But there are many many uses
44 | of TLS, for example the TLS1.2 RFC is currently (20170711) [referenced
45 | by](https://datatracker.ietf.org/doc/rfc5246/referencedby/) 434 other IETF
46 | specifications, and is
47 | [cited](https://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5)
48 | by 3,281 publications in Google Scholar. Accepting any proposal that might
49 | weaken such an important security protocol without due diligence is utterly
50 | unwise. And it is hard to see how anyone could really do that due diligence
51 | given the breadth of use of TLS today - both in openly specified foo/TLS
52 | applications but also in the presumably larger number of not publicly
53 | documented applications using TLS.
54 |
55 | 1. Note that I make no allegations about the bona-fides of any of the proponents
56 | of the "break-TLS" schemes. I know and respect some of them, but consider
57 | them misguided in contributing to proposals to break TLS. However, we cannot
58 | ignore the fact that some governments are very keen to weaken Internet security
59 | and privacy and have allocated significant budgets for that.
60 | [BULLRUN](https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security)
61 | for example is reported to have involved wasting/spending US$250M/yr on this.
62 | It is inevitable that some of that money ends up being spent/wasted on schemes
63 | to break or weaken TLS. The consequence of that is that it is entirely proper
64 | to consider the [Pervasive Monitoring](https://tools.ietf.org/html/rfc7258)
65 | aspects of any proposal as part of our [threat
66 | model](https://tools.ietf.org/html/rfc7624) no matter what motivations are set
67 | out by proponents. (And again, considering this says nothing at all proponents'
68 | motivations, it's just a thing that we have to consider regardless.)
69 |
70 | 1. TLS is already hard, as we have seen from two decades of exploits against
71 | implementations and, occasionally, against the protocol itself. The added
72 | complexity of any "break TLS" proposal makes that situation worse, and
73 | logically must do so. But we have more than argument to go on here - there is
74 | evidence for this from peer-reviewed academic studies and examination of TLS
75 | interception implementations, for example [Durumeric et
76 | al.](https://www.internetsociety.org/sites/default/files/ndss2017_04A-4_Durumeric_paper.pdf)
77 | found that "that nearly all [interception proxies] reduce connection security
78 | and many introduce severe vulnerabilities" whilst [de Carnavalet et
79 | al.](http://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf)
80 | performed a "systematic analysis uncovered that several of these tools severely
81 | affect TLS security on their host machines." So, where there is evidence
82 | publicly available, it seems to indicate that additional complexity (via
83 | proxies or other methods of breaking TLS) reduces security. To my knowledge,
84 | none of the proposed "break TLS" schemes has ever offered evidence that they
85 | would lead to an overall improvement in security.
86 |
87 | 1. In many cases like this people also argue that even if breaking TLS is
88 | undesirable, it's better to do that undesirable thing openly inside the IETF
89 | as it would happen elsewhere in any case and perhaps be done worse. Without
90 | specific evidence that organisation foo is about to take action bar, that
91 | argument is impossible to judge, so is at best neutral. When there is specific
92 | evidence of something relevant being done elsewhere, then the IAB and IESG have
93 | liaison mechanisms that can be used for the purpose for which they were
94 | designed. IOW, "if we don't, they will" is not a good argument that the IETF
95 | should do any particular thing at all. In the author's experience, this
96 | argument is commonly associated with proponents of proposals that might be fairly
97 | described as being engaged in forum shopping. In the case of "break TLS"
98 | proposals, one could argue (and I would) that the reason TLS is widely
99 | used is, in significant part, because TLS is not broken.
100 |
101 |
102 | 1. In 2014, the Internet Architecture Board issued a
103 | [statement](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/)
104 | to the effect that "Internet depended on users having confidence that the network would protect
105 | their private information" and that we should "make encryption the norm for Internet traffic."
106 | All proposals to break or weaken TLS go against that sound advice (not repeated
107 | here because we'd end up repeating almost all of it).
108 | The IAB statement
109 | recognises that increasingly widespread use of TLS causes issues
110 | for network operations, but no response that amounts to attempting to break TLS
111 | so far presented can be justified due to the huge potential cost and impact
112 | of breaking TLS.
113 |
114 | 1. Most or all approaches to breaking TLS seem to involve changing TLS from a
115 | two-party protocol (ignoring CAs for now) into a multi-party protocol, but
116 | one that mimics the behavior of TLS in order to have a chance to get deployed
117 | on the Internet. A multi-party transport security protocol however would
118 | require either a substantially different API or to move up the stack to solve
119 | whatever problem one is facing.
120 |
121 | 1. Some people argue that 20 years (or so) ago the IETF was wrong to have
122 | ignored the reality of NAT deployments, and draw a comparison with breaking
123 | TLS, particularly in enterprise gateways. They draw the erroneous conclusion
124 | that the IETF should therefore standardise ways to break TLS, as a way of
125 | dealing with what is the sad reality for some networks,
126 | where TLS is intercepted. Firstly, by itself that's not good logic, as it would
127 | mean that the IETF should standardise anything that is deployed without
128 | exercising any judgement. But most people making the argument probably don't
129 | really mean that and implicitly think that some level of TLS interception is
130 | unavoidable. But regardless of what one thinks about NAT, the conclusion that
131 | we ought therefore break TLS remains erroneous - recognising the existence of
132 | NAT would not have directly damaged networks that do not use NAT, whereas
133 | breaking TLS causes breakage and damages trust for all applications using TLS,
134 | for all time - the impact here would be far broader than just the networks
135 | already suffering TLS interception. So the equivalent argument really would be:
136 | should the IETF have entirely given up on the end-to-end argument because of
137 | NAT deployments or not? And the answer to that is "no," just as the answer
138 | when asked to standardise breaking TLS is "no." The bottom line is that the
139 | "it's just like NAT, the network suffered because we ignored NAT, so we
140 | should break TLS" argument is fallacious.
141 |
142 | 1. [Ben Kaduk](https://www.ietf.org/mail-archive/web/tls/current/msg24620.html)
143 | raised a general issue that is a problem whether or not break-TLS proposals
144 | try to be an "opt-in" by
145 | making themselves visible to TLS clients: if they do not, then they fail
146 | to be transparent (as in
147 | [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01)
148 | ), but if they do make themselves visible in a way that a network intermediary
149 | can see, then "once a visible ClientHello extension is needed to enable wiretapping,
150 | certain parties (e.g., national border firewalls) would reject/drop
151 | *all* ClientHellos not containing that extension, thereby extorting all
152 | clients into "opting in" to the wiretapping and effectively rendering
153 | the "opt-in" requirement useless for those clients." And it seems hard
154 | to propose an opt-in scheme where the opting-in or not is not
155 | detectable by an on-path intermediary.
156 |
157 | 1. Even though the stated goal of these proposals is to allow monitoring
158 | of the connection contents, exposing the session keys to a third-party
159 | also allows said third-party to modify the connection contents, that is,
160 | TLS loses not only confidentiality, but also integrity.
161 |
162 | ## Specific "break-TLS" proposals
163 |
164 | Current Proposals
165 |
166 | ### [draft-rhrd-tls-tls13-visibility-00](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
167 |
168 | Since it helps to have a pronounceable name for things, I'm personally calling
169 | this draft [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
170 | on the basis of the output of:
171 |
172 | $ grep "^r.h.r.d" /usr/share/dict/words
173 | rehired
174 |
175 |
176 | ### Arguments already raised in the [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01) debacle:
177 |
178 | These arguments were raised but not substantively dealt with
179 | in the discussion of [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01), but remain telling. (And
180 | again, only one killer argument needs to be accepted to
181 | see off this latest bad idea.) Some of the wording has
182 | been tweaked for
183 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00),
184 | but mainly the arguments are the same, and as good as ever.
185 |
186 | 1. The [TLS working group charter](https://tools.ietf.org/wg/tls/charters)
187 | dated 2017-03-30 calls for improving the security of TLS, and
188 | this proposal involves leaking secret key material to
189 | unnamed third parties and hence clearly falls outside the charter.
190 |
191 | 1. TLS1.3 (and DTLS1.3) are still not finished and any
192 | work within the IETF on this draft will put those efforts
193 | at risk. For example, the abstract of the latest
194 | [TLS1.3 draft](https://tools.ietf.org/html/draft-ietf-tls-tls13-21)
195 | says that TLS is "designed to prevent eavesdropping" - changes
196 | to that and possibly many other claims would be needed
197 | if the TLS working group adopted this, or any similar, draft.
198 | Those changes would not all be editorial and would likely
199 | be time-consuming. [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00) is worse than draft-green
200 | in this respect as it is very unclear how the extensions
201 | here fit into the overall lifecycle of TLS sessions between
202 | two entities (e.g. what about 0rtt replayable data?). Adopting
203 | this now would set back TLS1.3 by at least a year.
204 |
205 | 1. TLS1.3 has undergone significant academic and other analyses,
206 | (including two academic workshops,
207 | [TRON](https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme)
208 | in 2016, and [TLS-DIV](https://www.mitls.org/tls:div/) in 2017),
209 | none of which
210 | (to my knowledge) envisaged the use of key escrow, nor of
211 | "farms" of TLS servers using the same SSWrapDH1.
212 | Adoption of any work in this space could require
213 | re-doing some of the analysis work, possibly delaying TLS1.3 or (worse)
214 | resulting in new problems being found after widespread deployment. Given that
215 | this draft would create new active and passive attack possibilities, such new
216 | analysis work would seem to be required, especially if proprietary
217 | uses of the awfully-named "tls_visibility"
218 | extension were to emerge (which seems likely).
219 |
220 | - The work done by academic analyses of TLS1.3 has been valuable in terms
221 | of improving the quality of the IETF's output. Radical changes to TLS1.3 at this point
222 | will likely disincent researchers from contributing as a part of the process
223 | in future as they may perceive the IETF to be moving the goalposts at the
224 | last minute, indicating that IETF participants do not value their inputs.
225 | (I admit that is speculative, but it's based on some previous discussions on the WG
226 | list - it'd be good to get feedback from researchers to check.)
227 |
228 | 1. There could be similar problems caused for the QUIC protocol development
229 | work, as that relies upon TLS1.3 and has similar design elements that
230 | could be perturbed if session keys are leaky.
231 |
232 | 1. This draft tries to standardise broken crypto - forward
233 | secrecy is a goal of cryptographic protocols and this
234 | draft deliberately aims to not provide forward secrecy
235 | and indeed to break forward secrecy. [BCP200](https://datatracker.ietf.org/doc/rfc1984/)
236 | (which was promoted to BCP in 2015, and so is very
237 | recent) specifically argues against such schemes:
238 |
239 | - "Escrow mechanisms inevitably weaken the security of the overall
240 | cryptographic system, by creating new points of vulnerability that
241 | can and will be attacked."
242 |
243 | - "KEYS SHOULD NOT BE REVEALABLE
244 | The security of a modern cryptosystem rests entirely on the secrecy
245 | of the keys. Accordingly, it is a major principle of system design
246 | that to the extent possible, secret keys should never leave their
247 | user's secure environment. Key escrow implies that keys must be
248 | disclosed in some fashion, a flat-out contradiction of this
249 | principle. Any such disclosure weakens the total security of the
250 | system."
251 |
252 | - "Even if escrowed encryption schemes are used, there is nothing to
253 | prevent someone from using another encryption scheme first.
254 | Certainly, any serious malefactors would do this; the outer
255 | encryption layer, which would use an escrowed scheme, would be used
256 | to divert suspicion."
257 |
258 | - "A major threat to users of cryptographic systems is the theft of
259 | long-term keys (perhaps by a hacker), either before or after a
260 | sensitive conversation. To counter this threat, schemes with
261 | "perfect forward secrecy" are often employed. If PFS is used, the
262 | attacker must be in control of the machine during the actual
263 | conversation. But PFS is generally incompatible with schemes
264 | involving escrow of private keys. (This is an oversimplification,
265 | but a full analysis would be too lengthy for this document.)"
266 |
267 | - Note that while the concept of key escrow that was being
268 | promulgated in the mid 1990's is not identical to that
269 | being proposed here, the same vulnerabilities are
270 | created once one leaks private key materials, especially
271 | via a "standard" interface.
272 |
273 | 1. The argument has been made that it would be better
274 | to scrutinise proposals such as this openly in the IETF
275 | instead of having individual vendors develop their
276 | own bad-crypto implementations. As a counter to that,
277 | while scrutiny is good for good crypto, the overall
278 | ecosystem will be harmed by widespread use of the
279 | same bad-crypto, so therefore in the case of
280 | bad-crypto proposals such as this, it is better for
281 | us all that there is not a single bad-crypto standard.
282 | In [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00) there is in fact nothing to stop
283 | the server and third parties using crap-crypto without anyone else knowing.
284 |
285 | 1. If this scheme were widespread, it would be "accidentally" deployed in places
286 | for which it was not intended. (See also
287 | [RFC2804](https://tools.ietf.org/html/rfc2804).) The result could be active
288 | attacks on e.g. widely downloaded web resources enabling active attacks on
289 | browsers. I would expect another decade of academic publications and real
290 | exploits on TLS to result.
291 |
292 | 1. Applications built on TLS, e.g. the Web, would need to revise their security
293 | models to take into account this scheme, as it changes the threat model on
294 | which they have been built.
295 |
296 | 1. For the enterprise uses claimed to justify this, there is no need for
297 | Internet-scale interoperability as the enterprise network is by-definition
298 | under a single entity's control. (And if they cannot control their network,
299 | then adding broken crypto seems even more unwise.)
300 |
301 | 1. Ossification: this draft would introduce new ways of ossifying TLS, for
302 | example, the holder of the private component of SSWrapDH1 would have to be able to handle all
303 | updated ciphersuites before those could be used by bona-fide TLS clients and
304 | servers. We have seen that non-updated PKCS#1.5 crypto hardware has caused
305 | problems with updating the crypto in TLS for decades now, and this would cause
306 | similar problems.
307 |
308 | ### And here are some more [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00) specific reasons to not do this:
309 |
310 | Again, it's a pain to have to beat up on a -00, but that seems to
311 | be what's needed, so here we go...
312 |
313 | I'm focusing here on the fundamental errors in [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00) and
314 | hopefully less on the bits that could in theory be "improved."
315 | (Noting that "improving" is an oxymoron here;-)
316 |
317 | 1. The title and abstract are significantly misleading. This proposal enables
318 | an active attacker on the TLS session in question. The title and abstract seem
319 | to this reader as if designed to minimise or to attempt to obfuscate this fact.
320 | (Previous attempts to break TLS have also apparently required such misnomers,
321 | e.g. via the abuse of the term "passive" or "trusted proxy.")
322 |
323 | 1. There still is no real blood-brain barrier between uses of TLS that do or do
324 | not involve data centres. The presentation and analysis here are (and must be)
325 | woefully incomplete. Adopting a change to such a widely deployed protocol as
326 | TLS with such a dearth of analysis would be irresponsible of the WG and
327 | of the IETF.
328 |
329 | 1. [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00) claims that the third parties are "authorized"
330 | but that is not the case - the client has no say in which 3rd parties
331 | end up with the keys, nor is the client even told about which
332 | third parties get to see and possibly modify all their traffic.
333 | And the server doesn't even have to have a name for the wiretapper.
334 | (Adding names will not help however - this goes back to the problem
335 | of trying to abuse a 2-party protocol for >2 parties.)
336 |
337 | 1. Despite the design-goal of client opt-in
338 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
339 | would nicely enable state-level snooping and modification of TLS traffic
340 | *without client knowledge* - all that would be needed is to mandate that the
341 | value of the server's TLSVisibilityExtension be provided to the surveillance
342 | infrastucture and the TLS extensions be omitted from the handshake. Once server
343 | code supports this as-written, then that could easily be done out of band -
344 | there is nothing in this proposal that cryptographically *requires* the client
345 | to even know about the leaked keys/snooping.
346 |
347 | 1. The concept that TLS clients will "consent" to this is risible - general TLS
348 | clients could be mandated by local regulation to emit the "please screw me"
349 | extension. What browser chrome would then be displayed? There are no
350 | good answers there, nor is there any way for a TLS client user (when a person)
351 | to choose when to send the "please screw me" extension. Due to scarce
352 | screen real estate some applications on mobile devices will thus send this
353 | always, utterly undermining TLS. And the so-called "consent" situation
354 | for other applications is completely unknown.
355 |
356 | 1. Enterprise TLS clients unlucky enough to be forced to send this will not be
357 | able to distinguish enterprise-local from remote wiretapping, and nor will
358 | enterprise infrastructure unless it maintains an up-to-the minute white-list of
359 | allowed wiretapper fingerprints. In addition to not matching any sensible
360 | enterprise policy, that would also even further encourage enterprises to MITM
361 | all outbound TLS with all the known-bad consequences.
362 |
363 | 1. Multiparty imperfect forward secrecy: While forward secrecy is a goal
364 | for cryptographic protocols, it is rarely perfect, despite earlier
365 | uses of the term. In particular, performance reasons may call for use
366 | of tickets or other structures that are stored and that could break
367 | forward secrecy, typically if the server suffers a breach. With TLS
368 | as-is, the trade-offs in term of how imperfect to allow one's forward
369 | secrecy to be is essentially a matter for the TLS endpoints. With
370 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
371 | both the server and the snooper are now involved in deciding how
372 | imperfect to make forward secrecy. Given there is no real
373 | protocol between those (and nothing that involves the client),
374 | the fairly predictable end-result will be very long and hard to
375 | change durations during which sessions are at risk due to a breach
376 | in one place. (Breach in snooper is clear, same applies in the
377 | TLS server though, as whoever breaks in can replace the snooper's
378 | DH with their own.) Multi-party control over cryptographic
379 | parameters such as this seems hugely unwise.
380 |
381 | 1. Inter-snooper relationships: If a protocol like
382 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
383 | were standardised, there would be an immediate call to generalise that
384 | to more than one snooper. In discussion of this on the ilst,
385 | [Florian Weimer](https://www.ietf.org/mail-archive/web/tls/current/msg24607.html)
386 | raised the point that one might require none of the snoopers are
387 | aware of one another, or one might require
388 | that all the snoopers
389 | are aware of all the other snoopers. Similarly, the real TLS endpoints
390 | might be required to know about some or all of the snoopers. This
391 | situation seems laden with contradictions. For example, if the client knows
392 | all the snoopers, then any snooper can create a new TLS session with
393 | the same server and discover something about all the snoopers.
394 |
395 | 1. Sending the "please screw me" extension (in clear) in the ClientHello is
396 | broadcasting/advertising the vulnerability.
397 |
398 | 1. On the other direction, the extension in the ServerHello identifies
399 | not only the presence of the vulnerability, but also which long-term key
400 | should be stolen to be able to decrypt the connection.
401 |
402 | 1. Yes, despite the author's efforts, this would still
403 | enable wiretapping as defined in
404 | [RFC2804](https://tools.ietf.org/html/rfc2804).
405 | The figure below is one of possibly many scenarios to
406 | demonstrate that: if the browser is unlucky enough to
407 | be behind e.g., some corporate TLS MITM attacker (a not unlikely
408 | scenario, that presumably the authors of
409 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
410 | are happy enough to encourage) then that MITM proxy can be set
411 | to emit the "please screw me" ClientHello extension
412 | and any co-operating or coerced web servers will then
413 | emit the required session key information to allow
414 | the wiretapper to work happily on the Web. Enabling such
415 | scenarios is an inherent consequence of trying to make TLS a >2 party
416 | protocol.
417 |
418 |
419 |
420 | +-----------+ +--------------+ +----------+
421 | |browser +--+TLS MITM Proxy+--+---+Web server|
422 | +-----------+ +--------------+ | +-----+----+
423 | |
424 | |
425 | |
426 | -----------------
427 | | TLS decrypter |
428 | -----------------
429 |
430 | Figure: Browser wiretapping setup using
431 | https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00
432 |
433 |
434 |
435 | ### Some not-quite editorial issues...
436 |
437 | 1. Despite the extended debates on the WG list, this paragraph of the
438 | introduction is erroneous to the point of almost seeming disingeneous, it says:
439 |
440 | Specifically, the use of ephemeral ciphersuites prevents the use of
441 | current enterprise network monitoring tools such as Intrusion
442 | Detection Systems (IDS) and application monitoring systems, which
443 | leverage the current TLS RSA handshake to passively decrypt and
444 | monitor intranet TLS connections made between endpoints under the
445 | enterprise's control.
446 |
447 | Discussion on the TLS WG list has previously discredited such overly-broad assertions,
448 | on the basis that a) many people have asserted that these are non-problems
449 | for their real data-centres and b) those who like static RSA key transport can
450 | just keep using TLS1.2 *within their data-centres* for years to come. There is nothing that will prevent
451 | anyone from continuing to do that. (That is despite FUD-like
452 | claims about PCI-DSS - if one wanted to justify a PCI-DSS based claim
453 | one would need to point at the specific (but non-existent) PCI-DSS
454 | requirement for TLS1.3 or to one that requires plaintext access outside
455 | the transport endpoiints.
456 | None of the proponents of breaking-TLS has done that, despite repeated
457 | requests.)
458 |
459 | 1. "nearly always an improvement" are pretty much weasel-words.
460 | Either the authors agree with the IETF [BCP200](https://tools.ietf.org/html/bcp200)
461 | that forward secrecy is a best current practice, or they do not. If they did
462 | agree with BCP200 they presumably would not write this
463 | draft, which is designed to break forward-secrecy.
464 | If they disagree with BCP200, then they ought suggest a re-charter
465 | for the WG or a revision of BCP200.
466 |
467 | 1. It is worth noting the irony that one of the authors of
468 | draft-rehired was the IAB chair when the IAB correctly issued the IAB statement
469 | referred to above.
470 | Given this contrast, it is fair to quote from that IAB
471 | statement and consider how it is diametrically opposed
472 | to
473 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
474 |
475 | The IAB urges protocol designers to design for confidential operation by
476 | default. We strongly encourage developers to include encryption in their
477 | implementations, and to make them encrypted by default. We similarly encourage
478 | network and service operators to deploy encryption where it is not yet
479 | deployed, and we urge firewall policy administrators to permit encrypted
480 | traffic.
481 |
482 | We believe that each of these changes will help restore the trust users
483 | must have in the Internet.
484 |
485 | While one might attempt to argue that the above does not say "and oh,
486 | by the way, it is ok to hand out session keys to some unnamed parties so
487 | they can decrypt ciphertext" such an
488 | argument seems very unlikely to have been IAB member's mind whilst
489 | writing that statement - the IAB statement's words above argue for the opposite of
490 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00).
491 |
492 | 1. [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
493 | says that forward secrecy "may slow adoption of TLS 1.3 or force enterprises to
494 | continue to use outdated and potentially vulnerable technology" but then goes
495 | on to propose adding a specific and concrete actual vulnerability (key escrow)
496 | and one that would further ossify TLS1.3 (see above). Bad plan. As stated
497 | before, there's no reason why so-called "data centre" uses need to adopt TLS1.3
498 | now, nor why such data-centre internal uses of TLS would significantly slow
499 | adoption of TLS1.3 elsewhere.
500 |
501 | 1. TLS1.3 deliberately removed from TLS the option to send the session
502 | secrets encrypted with a long-term key.
503 | [draft-rehired](http://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00)
504 | reintroduces that possibility. That would be a step backwards in the protocol
505 | evolution.
506 |
507 |
508 | ## Other/Older/Dead Proposals
509 |
510 | Feel free to add analyses of older/other break-TLS here or even just links to
511 | drafts/papers. For now, other than
512 | [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01),
513 | I've just noted a few that'd deserve coverage if [the TLS WG think documenting
514 | those would be
515 | useful](https://www.ietf.org/mail-archive/web/tls/current/msg23909.html).
516 |
517 | ### [draft-green-tls-static-dh-in-tls13-01](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01)
518 |
519 | This July 2017 draft was a proposal for breaking TLS that
520 | was discussed at IETF 99, didn't [come anywhere near achieving
521 | rough consensusa](https://www.ietf.org/mail-archive/web/tls/current/msg24172.html) and so is hopefully dead.
522 |
523 | It fails in the following ways:
524 |
525 | 1. The [TLS working group charter](https://tools.ietf.org/wg/tls/charters)
526 | dated 2017-03-30 calls for improving the security of TLS, and
527 | this proposal involves leaking private key material and hence
528 | clearly falls outside the charter.
529 |
530 | 1. Stephen Checkoway [raised](https://www.ietf.org/mail-archive/web/tls/current/msg23913.html) a different charter issue:
531 | "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.
532 | 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."
533 |
534 | 1. TLS1.3 (and DTLS1.3) are still not finished and any
535 | work within the IETF on this draft will put those efforts
536 | at risk. For example, the abstract of the latest
537 | [TLS1.3 draft](https://tools.ietf.org/html/draft-ietf-tls-tls13-21)
538 | says that TLS is "designed to prevent eavesdropping" - changes
539 | to that and possibly many other claims would be needed
540 | if the TLS working group adopted this, or any similar, draft.
541 | Those changes would not all be editorial and would likely
542 | be time-consuming.
543 |
544 | 1. As a result of the discussion of this draft, Christian Huitema has proposed a
545 | [pull request](https://github.com/tlswg/tls13-spec/pull/1049) for TLS1.3 to
546 | encourage implementers to effectively make the idea in this draft harder to deploy,
547 | by documenting the core static DH value idea as an attack against which
548 | TLS clients ought attempt to defend themselves.
549 | Adopting work on static DH values would therefore have the effect of forcing
550 | the working group to work against itself, further delaying and putting TLS1.3
551 | at risk.
552 |
553 | 1. TLS1.3 has undergone significant academic and other analyses,
554 | (including two academic workshops,
555 | [TRON](https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme)
556 | in 2016, and [TLS-DIV](https://www.mitls.org/tls:div/) in 2017),
557 | none of which
558 | (to my knowledge) envisaged the use of static DH values, nor of centrally
559 | generated DH values being "pushed" to many TLS servers. Similarly, work on the
560 | TLS application layer PDU protection didn't envise re-use of DH values in
561 | possibly many TLS sessions. Adoption of any work in this space could require
562 | re-doing some of the analysis work, possibly delaying TLS1.3 or (worse)
563 | resulting in new problems being found after widespread deployment. Given that
564 | this draft would create new active and passive attack possibilities, such new
565 | analysis work would seem to be required, especially if proprietary
566 | extensions to the proposed "TSK" protocol affect the cryptography used
567 | in TLS sessions.
568 |
569 | - The work done by academic analyses of TLS1.3 has been valuable in terms
570 | of improving the quality of the IETF's output. Radical changes to TLS1.3 at this point
571 | will likely disincent researchers from contributing as a part of the process
572 | in future as they may perceive the IETF to be moving the goalposts at the
573 | last minute, indicating that IETF participants do not value their inputs.
574 | (I admit that is speculative, but it's based on some previous discussions on the WG
575 | list - it'd be good to get feedback from researchers to check.)
576 |
577 | 1. Kenny Paterson (private communication, quoted with permission) notes that
578 | history has shown that static DH in TLS (and elsewhere) is not "implementation
579 | robust" - another relevant attack is
580 | [this](http://nds.rub.de/media/nds/veroeffentlichungen/2015/09/14/main-full.pdf)
581 | one which is quite spectacular.
582 |
583 | 1. There could be similar problems caused for the QUIC protocol development
584 | work, as that relies upon TLS1.3 and has similar design elements that
585 | could be perturbed if static DH private values were used. And QUIC has recently
586 | been
587 | [proposed](https://www.ietf.org/mail-archive/web/quic/current/msg01878.html) as
588 | a substrate for 5G efforts in another SDO with fairly aggressive timelines, so
589 | delays in developing QUIC caused by breaking TLS could have significant effects
590 | elsewhere.
591 |
592 | 1. This draft aims/claims to enable key-leaking/wiretapping only "within"
593 | enterprise networks, but there is no way (and cannot be a way)
594 | to constrain the use of this scheme to such (parts of) networks.
595 | Figure 3 of the draft (reproduced below) clearly describes a generic
596 | key-leaking/wiretapping architecture for TLS that could (and would)
597 | be used in many other circumstances that the authors
598 | have apparently not envisaged.
599 |
600 | - As pointed out on the list (e.g. by
601 | [Yoav Nir](https://www.ietf.org/mail-archive/web/tls/current/msg24070.html) and others), if there was
602 | a standard for this scheme, code for that would leak into being
603 | used on the public Internet via the normal implementations that
604 | are used both within and outside pretty much all networks.
605 |
606 | 1. We also have a documented case where a law enforcement agency
607 | has attempted to coerce a mail service provider
608 | called [Lavabit](https://en.wikipedia.org/wiki/Lavabit) into
609 | providing TLS private key materials. Developing an API
610 | such as envisaged in this draft would encourage such
611 | law enforcement and other agency attempts at key recovery in many countries.
612 | So the unintended uses for this are as real as the intended
613 | ones. (An aspect that is ignored by the draft and it's
614 | proponents.)
615 |
616 | 1. This draft is targeted as being an IETF standards track document
617 | but is a wiretapping scheme (or enables wiretapping) that meets the definition in
618 | [RFC2804](https://tools.ietf.org/html/rfc2804) and therefore
619 | cannot be a standards-track work item in the IETF.
620 |
621 | - Some may argue that even if this cannot be an
622 | IETF standards track specification, it should still be
623 | further developed by the IETF. IMO, (though this is
624 | guessing to an extent) that also goes against
625 | [RFC2804](https://tools.ietf.org/html/rfc2804)
626 | which calls for documentation, and not development,
627 | of deployed wiretapping schemes. Documenting the
628 | wiretapping schemes that exist is a good thing.
629 | Developing new ones is a bad thing, for all the
630 | reasons set out explicitly in RFC2804. As a
631 | speculative new wiretapping design, this draft
632 | should not be an IETF specification of any kind,
633 | so long as RFC2804 has not been obsoleted, and
634 | yet the authors here are making no attempt to
635 | obsolete RFC2804, and are thus attempting an end-run
636 | around IETF processes.
637 |
638 | - To my knowledge, all wiretapping schemes
639 | documented in RFC so far have been in the independent
640 | stream (hence not IETF documents) or perhaps pre-date
641 | RFC streams.
642 |
643 | - See below for more on this as a wiretapping
644 | proposal.
645 |
646 | 1. This proposal entirely suits what governments doing
647 | pervasive monitoring would need in an API. The IETF
648 | has documented its consensus that [Pervasive Monitoring is an Attack](https://tools.ietf.org/html/rfc7258)
649 | in RFC 7258, and this API would assist with such
650 | attacks. In case this seems somewhat abstract, we
651 | have evidence of exactly this kind of key exfiltration
652 | API in IPsec, as documented by [Wouters](https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/)
653 | and [Der Spiegel](http://www.spiegel.de/media/media-35515.pdf).
654 | In that case, a collector has ciphertext packets and calls
655 | a function (passing in initial packets) to get a key for
656 | packet decryption. An implementation of such a function
657 | could clearly benefit from the GET DH value API
658 | defined in this document.
659 |
660 | 1. This draft tries to standardise broken crypto - forward
661 | secrecy is a goal of cryptographic protocols and this
662 | draft deliberately aims to not provide forward secrecy
663 | and indeed to break forward secrecy. [BCP200](https://datatracker.ietf.org/doc/rfc1984/)
664 | (which was promoted to BCP in 2015, and so is very
665 | recent) specifically argues against such schemes:
666 |
667 | - "Escrow mechanisms inevitably weaken the security of the overall
668 | cryptographic system, by creating new points of vulnerability that
669 | can and will be attacked."
670 |
671 | - "KEYS SHOULD NOT BE REVEALABLE
672 | The security of a modern cryptosystem rests entirely on the secrecy
673 | of the keys. Accordingly, it is a major principle of system design
674 | that to the extent possible, secret keys should never leave their
675 | user's secure environment. Key escrow implies that keys must be
676 | disclosed in some fashion, a flat-out contradiction of this
677 | principle. Any such disclosure weakens the total security of the
678 | system."
679 |
680 | - "Even if escrowed encryption schemes are used, there is nothing to
681 | prevent someone from using another encryption scheme first.
682 | Certainly, any serious malefactors would do this; the outer
683 | encryption layer, which would use an escrowed scheme, would be used
684 | to divert suspicion."
685 |
686 | - "A major threat to users of cryptographic systems is the theft of
687 | long-term keys (perhaps by a hacker), either before or after a
688 | sensitive conversation. To counter this threat, schemes with
689 | "perfect forward secrecy" are often employed. If PFS is used, the
690 | attacker must be in control of the machine during the actual
691 | conversation. But PFS is generally incompatible with schemes
692 | involving escrow of private keys. (This is an oversimplification,
693 | but a full analysis would be too lengthy for this document.)"
694 |
695 | - Note that while the concept of key escrow that was being
696 | promulgated in the mid 1990's is not identical to that
697 | being proposed here, the same vulnerabilities are
698 | created once one leaks private key materials, especially
699 | via a "standard" interface.
700 |
701 | 1. Aside from the process/BCP perspective on "bad crypto" Nick Sullivan
702 | [pointed out](https://www.ietf.org/mail-archive/web/tls/current/msg23962.html)
703 | issues with the specific proposal: "Static Diffie-Hellman is a
704 | cryptographically problematic construction. Not only was it found to be fragile
705 | to implement in the prime field variant ([LogJam](https://weakdh.org/)), the
706 | Elliptic Curve variant has recently been identified as troublesome as well (see
707 | recent [JWE
708 | vulnerability](https://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html)
709 | and
710 | [CVE-2017-8932](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8932)).
711 | Furthermore, many post-quantum key exchange mechanisms cannot be secured with
712 | repeated key shares (SIDH is one example). Encouraging (or worse,
713 | standardizing) the repeated use of a key share seems risky and shortsighted. "
714 |
715 | 1. The argument has been made that it would be better
716 | to scrutinise proposals such as this openly in the IETF
717 | instead of having individual vendors develop their
718 | own bad-crypto implementations. As a counter to that,
719 | while scrutiny is good for good crypto, the overall
720 | ecosystem will be harmed by widespread use of the
721 | same bad-crypto, so therefore in the case of
722 | bad-crypto proposals such as this, it is better for
723 | us all that there is not a single bad-crypto standard.
724 |
725 | 1. Ironically, the first author of [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01)
726 | is also a co-author of [keys under doormats](https://dspace.mit.edu/openaccess-disseminate/1721.1/102271).
727 | While that latter report mainly considers government
728 | mandated back-doors, it does
729 | also correctly point out that:
730 | "Communications technologies designed to comply with government requirements for
731 | backdoors for legal access have turned out to be insecure. For ten months in 2004 and
732 | 2005, 100 senior members of the Greek government (including the Prime Minister, the
733 | head of the Ministry of National Defense and the head of the Ministry of Justice) were
734 | wiretapped by unknown parties through lawful access built into a telephone switch owned
735 | by Vodafone Greece [19]. In 2010 an IBM researcher observed that a Cisco architecture
736 | for enabling lawful interception in IP networks was insecure. 2 This architecture had
737 | been public for several years, and insecure versions had been implemented by several
738 | carriers in Europe [20]. And when the NSA examined telephone switches built to comply
739 | with government-mandated access for wiretapping, it discovered security problems with
740 | all the switches submitted for testing[21]. Embedding exceptional access requirements
741 | into communications technology will ensure even more such problems, putting not only
742 | private-sector systems, but government ones, at risk."
743 | The draft being discussed here is just enabling another form
744 | of exceptional access, despite being designed for
745 | enterprise-access and not for government access, so the fine points
746 | quoted above are as applicable.
747 |
748 | - One of the reactions to excessive government data retention has been to
749 | suggest requiring corporations to store the relevant (or all!) data and
750 | to then make that information available to government as needed. The API
751 | defined here could assist that kind of privatisation of government pervasive
752 | monitoring as a kind of federated government backdoor, if governments mandated
753 | use of this scheme.
754 |
755 | 1. A [suggestion](https://www.ietf.org/mail-archive/web/tls/current/msg23802.html)
756 | was made on the TLS list that the deployment
757 | of this scheme be made part of a "website's
758 | terms of service." Hiding the fact that one is
759 | breaking TLS in legalese seems like a terrible
760 | idea to this user of the web.
761 |
762 | 1. Whether or not use of this scheme is visible to the Internet
763 | has a number of consequences, all of which appear to be bad
764 | outcomes.
765 |
766 | - This scheme doesn't allow normal TLS clients (without visibility of DH
767 | re-use) and applications above or behind the TLS server to detect that
768 | wiretapping is occurring. That means we cannot know if their threat models
769 | match reality or not. That is essentially a layering issue - this, and all,
770 | "break TLS" proposals change the semantics of TLS without letting the
771 | applications and prtoocols that depend on TLS know that that change has
772 | happened.
773 |
774 | - To this reader, it is not clear whether or not deployments of the -01
775 | draft, would be detectable or not, from the Internet. (Detection could
776 | be visible to an "ordinary" client or might require a
777 | [zmap-like](https://zmap.io/) survey.) It is clear though that -01 has enough
778 | extension points so that an undetectable version of this scheme would be easy
779 | to invent and deploy.
780 |
781 | - A strawman undetectable version: change the CMS wrapper to indicate that the
782 | value contained therein is the RNG seed for a specific algorithm for
783 | generating a sequence of DH private values. Other than e.g. one new OID,
784 | that could look precisely the same as the current scheme. That should work
785 | fine for any situation where the TLS server and the TLS decrypter have
786 | similar CPU capabilities for the relevant traffic, which is probably many cases.
787 |
788 | - The upshot is: we cannot assume that this scheme will be
789 | detectable.
790 |
791 | - If use of this scheme is detectable,and if it is not widely used, it will
792 | likely fall out of use and end up worthless as the reputational cost of
793 | being shown to be a deployment of this would be high. ("Hey, all my cookies are
794 | leaked when I talk to example.com!") That means effort to scrutinise this in
795 | the IETF would be wasted.
796 |
797 | - If this is detectable and somehow is widely deployed, the impact of
798 | exploits of the inevitable vulnerabilities would be gigantic as many many
799 | TLS servers would offer an API to extract their DH private values.
800 | ("Hey, what domains TLS cleartext would you like to buy?")
801 |
802 | - If the scheme is initially detectable, and not very widely deployed
803 | (highly likely at least at first), then deployments will make
804 | modifications to the scheme to avoid detection. Such proprietary
805 | modifications mean that all effort to "improve" or "scrutinise" this scheme
806 | would certainly be wasted. Proprietary modifications could also significantly
807 | weaken security.
808 |
809 | 1. Developing this interface within the IETF would arguably increase the
810 | probability of "worse solutions" being deployed as those would be easier to
811 | integrate thanks to the existence of the "GET private key" API that TLS
812 | servers might then offer. An argument for this draft was
813 | [offered](https://www.ietf.org/mail-archive/web/tls/current/msg23817.html) that
814 | standardising it would avoid such "worse solutions" - I see no evidence offered
815 | and claim (with the same evidence;-) that the opposite would eventuate.
816 |
817 | 1. This scheme enables active attacks - once the DH private values are known,
818 | then all session keys are known and seemingly valid packets can be injected
819 | into ongoing sessions. The abstract of the -01 draft is extremely misleading in
820 | claiming that it is for "passive monitoring." No mention is made in the draft
821 | of the active attacks it enables.
822 |
823 | 1. If this scheme were widespread, it would be "accidentally" deployed in places
824 | for which it was not intended. (See also
825 | [RFC2804](https://tools.ietf.org/html/rfc2804).) The result could be active
826 | attacks on e.g. widely downloaded web resources enabling active attacks on
827 | browsers. I would expect another decade of academic publications and real
828 | exploits on TLS to result.
829 |
830 | 1. Applications built on TLS, e.g. the Web, would need to revise their security
831 | models to take into account this scheme, as it changes the threat model on
832 | which they have been built.
833 |
834 | 1. For the enterprise uses claimed to justify this, there is no need for
835 | Internet-scale interoperability as the enterprise network is by-definition
836 | under a single entity's control. (And if they cannot control their network,
837 | then adding broken crypto seems even more unwise.)
838 |
839 | 1. Ossification: this draft would introduce new ways of ossifying TLS, for
840 | example, the so-called "TLS decrypter" would have to be able to handle all
841 | updated ciphersuites before those could be used by bona-fide TLS clients and
842 | servers. We have seen that non-updated PKCS#1.5 crypto hardware has caused
843 | problems with updating the crypto in TLS for decades now, and this would cause
844 | similar problems.
845 |
846 | 1. Brian Carpenter points out (private communication, quoted with permission)
847 | that "server load balancing and TLS load balancing don't mix well. (See
848 | [RFC7098](https://tools.ietf.org/html/rfc7098) for more.) In fact, there's no
849 | practical alternative for large server farms except TLS proxying in front of
850 | the servers. At a quick glance it seems to me that [draft-green](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01) doesn't
851 | separate this issue from the rest. But server farms have no choice about
852 | solving that problem, or the intrusion/DOS detection problem, but they do have
853 | a choice about monitoring as such. Separating the operational requirements
854 | from the political requirements might be a good first step."
855 |
856 | 1. IPR: As of 20170727, there are a couple of [IPR declarations](https://datatracker.ietf.org/ipr/search/?id=draft-green-tls-static-dh-in-tls13&submit=draft) to be considered.
857 |
858 | 1. Paul Wouters mentioned that the IETF is deprecating some DH groups
859 |
860 | 1. mnot: https is 2 party, there's no way to get informed consent to change
861 | that, same here
862 |
863 | 1. Ted Hardie: PFS is a feature, you can't tell on 1st connection for sure that it's
864 | been removed and that's a basic feature, and hence needs to be indicated,
865 | this doesn't meet that basic protocol feature.
866 |
867 | While I'm reluctant to comment on the details of a bad
868 | design, there are a couple of things to point out:
869 |
870 | 1. The fact that this draft both breaks and depends
871 | upon TLS (in it's use of HTTP/TLS via RFC2818) means
872 | that this drafts enables "meta-attacks" where another
873 | party can eavesdrop on the connections between the
874 | various TLS-breaking components defined here, if (as
875 | would seem likely to me) the OPTIONAL additional CMS
876 | protection is not used. Similarly,
877 | such a meta-attacker could likely inject chosen DH
878 | values into a deployment.
879 |
880 | 1. [Section 7.2](https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01#section-7.2)
881 | defines a key request interface, but defines no authorisation
882 | scheme, no HTTP authentication, and requires no additional CMS
883 | protection.
884 | This creates an excellent target to attempt to find
885 | when one has breached some network. That is an excellent
886 | example of the kind of additional vulnerability
887 | created by these schemes called out in BCP200 and
888 | [RFC2804](https://tools.ietf.org/html/rfc2804).
889 | There is ample recent evidence [Wannacry](https://en.wikipedia.org/wiki/WannaCry_ransomware_attack)
890 | that many enterprises are not capable of shutting down
891 | or controlling such interfaces that either ought not be
892 | offered or need to be protected.
893 |
894 | 1. Richard Barnes [points out](https://www.ietf.org/mail-archive/web/tls/current/msg23793.html)
895 | that there may be "unstated requirements here to support for resumption
896 | (without having to find the previous session) and probably 0xRTT, and those
897 | modes use in a shared secret in addition to the DH secret. So you would need
898 | to exfiltrate the PSK as well." If correct, that would seem to
899 | indicate that this proposal is broken.
900 |
901 | 1. The use of CMS means that there are already a vast array of possible (even
902 | deployment-specific) extension points in this protocol. That means that it is
903 | not possible to have any confidence that what would be designed is what would
904 | be deployed. In fact, given the detectability issues above, it seems very
905 | likely that non-detection (meaning non-compliance with the putative RFC) will be
906 | a goal for implementers.
907 |
908 | IMO none of the above ought not be fixed by IETF participants collectively.
909 |
910 | #### Why is this wiretapping?
911 |
912 | Some IETF TLS WG list participants have denied that this is a wiretapping
913 | proposal, based on it somehow not matching the definitions in
914 | [RFC2804](https://tools.ietf.org/html/rfc2804).
915 | Firstly, that is far too lawyerly and IMO being overly pedantic with the 2804
916 | definitions. If one looks at Figure 3 in the draft, it very clearly matches any
917 | intuitive definition of (an API for) a wiretapping technology. The "TLS decrypter" can be
918 | anywhere on the Internet, so long as it has access to the key-leaking API.
919 | If some local government coerced some local popular web site into implementing
920 | this scheme so that the local government has access to the content of any TLS
921 | session with that web site, then I think it'd be insane to not consider that a wiretap on
922 | the web site in question.
923 |
924 |
925 | -------------- -----------------
926 | | TLS server |-------| key manager |
927 | -------------- -----------------
928 | | |
929 | | |
930 | | |
931 | | -----------------
932 | |------------>| TLS decrypter |
933 | | -----------------
934 | |
935 | |
936 | --------------
937 | | TLS client |
938 | --------------
939 |
940 |
941 | Figure 3: TSK protocol components
942 | (copied from https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01)
943 |
944 |
945 | However, we can also easily see how the 2804 definitions are still met,
946 | even taking a lawyerly approach...
947 |
948 | 1. With SMTP/TLS and with any intermediate MTA, (so 3 MTAs on the path) this
949 | clearly allows that intermediate MTA to renege and leak
950 | their private values and hence senders and recipients will
951 | not get the confidentiality they expect. Note that SMTP/TLS
952 | is almost ubiquitous today and that 2-TLS session setups
953 | are common, e.g. if the intermediary MTA does AV scanning.
954 | In this case, the relevant parties to the communication
955 | (for the RFC2804 definition) are the mail senders and
956 | receivers and the AV scanning MTA is the third party
957 | that enables wiretapping, just as a telco (with whom
958 | the caller or callee presumably has a contract) is the
959 | third party in traditional wiretaps.
960 |
961 | - In case of doubts about the scale of SMTP/TLS deployment, see
962 | [Google's saferemail](https://www.google.com/transparencyreport/saferemail/)
963 | statistics which shows nearly 90% of mails outbound from gmail.com being
964 | encrypted with TLS now. In many mail deployments there will be an added hop
965 | e.g. for anti-spam (we do that here in TCD/tcd.ie) to an outside party (in our
966 | case outlook.com). (On days when we get enough inbound mail from gmail to be
967 | visible in their published DB;-) 100% of mails from gmail.com to tcd.ie are
968 | sent via TLS to a host below outlook.com for AV scanning and then on to the TCD
969 | MTA, also using TLS. That's perhaps some 10's of thousands of mails per day
970 | for the 3,000 staff and 20,000 students in TCD.
971 | I'd guess outlook have thousands of customers, so if this draft were deployed
972 | in that AV scanning MTA infrastructure, that could put at risk the
973 | confidentiality of tens to hundreds of millions of emails per day. So, while
974 | less than 100% of mail is encrypted with TLS on all hops, much is. As [pointed
975 | out](https://www.ietf.org/mail-archive/web/tls/current/msg23843.html) on the
976 | TLS list, the UTA working group are also developing MTA-STS to try improve that
977 | situation, so any argument that mail senders and receivers do not expect
978 | confidentiality is sadly outdated.
979 |
980 |
981 |
982 | +-----------+ +--------------+ +----------+ +---------+ +-------------+
983 | |mail sender+--+Submit server +--+---+AV scanner+-----+Recip MTA+--+mail receiver|
984 | +-----------+ +--------------+ | +-----+----+ +---------+ +-------------+
985 | | |
986 | | |
987 | | |
988 | ----------------- ----------------
989 | | TLS decrypter |-------| key manager |
990 | ----------------- ----------------
991 |
992 | Figure: SMTP/TLS wiretapping setup using
993 | https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
994 |
995 |
996 |
997 | 1. As another example, consider (esp. vanity domain) web sites where
998 | the domain holder doesn't have shell access to the
999 | machine that hosts the web site.
1000 | If the hoster in that case turns on this
1001 | interface and provides private DH values to someone who
1002 | has access to the ciphertext TLS packets, then that is
1003 | clearly wiretapping. That is especially clear if e.g.
1004 | to people are using such a web site to communicate
1005 | with one another via some wordpress plug-in.
1006 | In this scenario the two people who
1007 | are using some wordpress plugin to communicate
1008 | are the first and second parties and the hoster is
1009 | the third party, in the role of the telco in a
1010 | traditional wiretap.
1011 |
1012 | - And again, this is a real scenario: [wordpress.com](https://wordpress.com/)
1013 | has millions of such users, as do many many other hosted
1014 | sites where those communicating do not have access to
1015 | a shell or to the TLS server configuration.
1016 |
1017 |
1018 |
1019 | +--------------+ +---------------+ +--------------+
1020 | |blog commenter+---+---+Hosted Web Site|----+---+blog commenter|
1021 | +--------------+ | +-------+-------+ | +--------------+
1022 | | | |
1023 | | | |
1024 | | -------+-------- |
1025 | | | key manager | |
1026 | | ---------------- |
1027 | | | |
1028 | | | |
1029 | | --------+-------- |
1030 | +---+ TLS decrypter +----+
1031 | -----------------
1032 |
1033 | Figure: Hosted web site wiretapping setup using
1034 | https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
1035 |
1036 |
1037 |
1038 | It does not matter that in these cases the third
1039 | party (AV scanner or hoster) has access to the
1040 | cleartext but does not supply that to the consumer
1041 | of the wiretap - whether the wiretap is based
1042 | on runtime or later decryption of captured packets,
1043 | or on playing back physical tapes of a conversation,
1044 | or on consuming a live feed from the telco-equivalent
1045 | is immaterial - the end result is that the first
1046 | and second parties communications are being
1047 | wiretapped according to the definitions in RFC2804.
1048 |
1049 | ### [TLS-RaR](https://nsr.cse.buffalo.edu/mobisys_2017/papers/pdfs/mobisys17-paper32.pdf)
1050 |
1051 | From the abstract: "This paper presents TLS–Rotate and Release (TLS-RaR),
1052 | a system that allows device owners (e.g., consumers, security
1053 | researchers, and consumer watchdogs) to authorize devices,
1054 | called auditors, to decrypt and verify recent TLS traffic
1055 | without compromising future traffic."
1056 |
1057 | Analysis TBD.
1058 |
1059 |
1060 | ### [mcTLS](https://mctls.org/)
1061 |
1062 | This was a [sigcomm publication](http://www.cs.cmu.edu/~dnaylor/mcTLS.pdf)
1063 | (sigcomm went down in my estimation for accepting that) assuming that it makes
1064 | sense for the random IP address (of a middlebox) to be somehow authorised by
1065 | the endpoints in a TLS sesssion to join in as a 3rd party in a TLS session.
1066 |
1067 | ### http/2 Related Proposals
1068 |
1069 | These drafts were proposed during the development of http/2.
1070 |
1071 | - In 2014: [draft-loreto-httpbis-trusted-proxy20-01](https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01)
1072 | - In 2013: [draft-vidya-httpbis-explicit-proxy-ps-00](https://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00)
1073 | - In 2012: [draft-rpeon-httpbis-exproxy-00](https://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00)
1074 |
1075 | ### [draft-mcgrew-tls-proxy-server-01](https://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01)
1076 |
1077 | This was a draft from people working on so-called "Next Generation Firewalls".
1078 | Such firewall products typically include a client-side TLS proxy that has a
1079 | Certification Authority (CA) and signs "fake certificates" (that is what the
1080 | vendors call them internally) for the websites that clients behind those proxies
1081 | attempt to connect to.
1082 |
1083 | The interception is usually visible to the clients, because they have to be configured
1084 | to trust the interception CA, but in some [well-publicized cases](https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-what-happens-next/)
1085 | (mis-)trusted CAs issued sub-CA certificates for such purposes. Even when used as intended,
1086 | the interception is invisible to the TLS server. The interception also hinders the client's
1087 | ability to validate the server certificate, because the client only sees the fake certificate.
1088 | This prevents the client from displaying the Extended Validation indication for server certificates.
1089 |
1090 | The draft was intended to make the real certificate visible to the client and to make the
1091 | interception detectable to the server in order to alleviate those limitations. The TLS WG
1092 | did not want to adopt this work, and the draft was abandoned.
1093 |
1094 |
1095 |
1096 |
1097 |
--------------------------------------------------------------------------------