idnits 2.17.1 draft-martini-hrpc-quichr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8280]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 553: '... SHOULD be an UTF-8 string, while UT...' RFC 2119 keyword, line 555: '...mended that this SHOULD becomes a MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1070 -- Looks like a reference, but probably isn't: '2' on line 1072 -- Looks like a reference, but probably isn't: '3' on line 1074 == Unused Reference: 'Cuietal' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'Gratzer' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 991, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-hall-censorship-tech-01 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group B. Martini 3 Internet-Draft Harvard Kennedy School 4 Intended status: Informational N. ten Oever 5 Expires: April 25, 2019 University of Amsterdam 6 October 22, 2018 8 QUIC Human Rights Review 9 draft-martini-hrpc-quichr-00 11 Abstract 13 QUIC is a new transport protocol that provides low-latency 14 communication and security. QUIC's key features include faster 15 connection establishment, stream-based multiplexing, improved loss 16 recovery, and no head-of-line blocking. This document assesses the 17 potential human rights implications emerging from the deployment of 18 QUIC. The assessment is done based on the methodology articulated in 19 [RFC8280]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Vocabulary Used . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Review Methodology and Process . . . . . . . . . . . . . . . 5 58 4. Human Rights Considerations . . . . . . . . . . . . . . . . . 7 59 4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1.1. Latency . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1.2. Congestion Control and Loss Recovery . . . . . . . . 8 62 4.1.3. Reduced Head-Of-Line Blocking . . . . . . . . . . . . 8 63 4.1.4. Resources . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.2. Transparent Proxying . . . . . . . . . . . . . . . . 9 67 4.2.3. Multiple Streams . . . . . . . . . . . . . . . . . . 9 68 4.2.4. Packet Number Encryption . . . . . . . . . . . . . . 9 69 4.2.5. Padding . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.6. Lawful Intercept . . . . . . . . . . . . . . . . . . 10 71 4.2.7. Spin Bit . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2.8. Packet Injection . . . . . . . . . . . . . . . . . . 11 73 4.3. Content Agnosticism . . . . . . . . . . . . . . . . . . . 12 74 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.5. Internationalization . . . . . . . . . . . . . . . . . . 12 76 4.6. Censorship Resistance . . . . . . . . . . . . . . . . . . 12 77 4.7. Open Standards . . . . . . . . . . . . . . . . . . . . . 13 78 4.8. Heterogeneity Support . . . . . . . . . . . . . . . . . . 13 79 4.9. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.10. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . 13 81 4.11. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 82 4.12. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.13. Authenticity . . . . . . . . . . . . . . . . . . . . . . 14 84 4.14. Adaptability . . . . . . . . . . . . . . . . . . . . . . 14 85 4.15. Outcome Transparency . . . . . . . . . . . . . . . . . . 14 86 4.15.1. Encryption . . . . . . . . . . . . . . . . . . . . . 15 87 4.15.2. Permissionless Innovation and Its Challenges . . . . 15 88 4.15.3. Privacy, Power and Consolidation . . . . . . . . . . 16 89 4.15.4. Transparency and IoT . . . . . . . . . . . . . . . . 17 90 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 18 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 9. Review Team Information . . . . . . . . . . . . . . . . . . . 19 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 10.1. Informative References . . . . . . . . . . . . . . . . . 19 97 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 This is a review done within the framework of the Human Rights Review 103 Team, and it was conducted by Beatrice Martini and Niels ten Oever. 104 The Human Rights Review Team aims to implement and improve the 105 guidelines for human rights considerations provided in [RFC8280], and 106 seeks to mitigate potentially adverse human rights impacts that IETF 107 and IRTF documents might have. 109 Human Rights Reviews are developed by a group of individuals in the 110 IRTF and IETF. They work collaboratively and provide their knowledge 111 and input to the assessments, in an effort to contribute to the IETF 112 open review process. Human Rights Reviews are individual 113 contributions. The authors hope that the comments will be taken into 114 consideration by the draft authors, Working Groups and the IESG. 116 This review concerns the QUIC protocol in general, and the following 117 drafts in particular: draft-ietf-quic-transport-12, draft-ietf-quic- 118 tls-12, draft-ietf-quic-invariants-01. 120 2. Vocabulary Used 122 Anonymity The condition of an identity being unknown or concealed 123 [RFC4949]. 125 Censorship Technical mechanisms, including both blocking and 126 filtering, that state or private actors can use to block or 127 degrade Internet traffic. For further details on the various 128 elements of Internet censorship, see [Halletal]. 130 Censorship resistance Methods and measures to mitigate Internet 131 censorship. 133 Confidentiality The property that data is not disclosed to system 134 entities unless they have been authorized to know the data 135 [RFC4949]. 137 Connectivity The extent to which a device or network is able to 138 reach other devices or networks to exchange data. The Internet is 139 the tool for providing global connectivity [RFC1958]. Different 140 types of connectivity are further specified in [RFC4084]. 142 Content agnosticism Treating network traffic identically regardless 143 of content. 145 Heterogeneity "The Internet is characterized by heterogeneity on 146 many levels: devices and nodes, router scheduling algorithms and 147 queue management mechanisms, routing protocols, levels of 148 multiplexing, protocol versions and implementations, underlying 149 link layers (e.g., point-to-point, multi-access links, wireless, 150 FDDI, etc.), in the traffic mix and in the levels of congestion at 151 different times and places. Moreover, as the Internet is composed 152 of autonomous organizations and Internet service providers, each 153 with their own separate policy concerns, there is a large 154 heterogeneity of administrative domains and pricing structures." 155 [FIArch] 157 As a result, per [FIArch], the heterogeneity principle proposed in 158 [RFC1958] needs to be supported by design. 160 Human rights Principles and norms that are indivisible, 161 interrelated, inalienable, universal, and mutually reinforcing. 162 Human rights have been codified in national and international 163 bodies of law. The Universal Declaration of Human Rights [UDHR] 164 is the most well-known document in the history of human rights. 165 The aspirations from [UDHR] were later codified into treaties such 166 as the International Covenant on Civil and Political Rights 167 [ICCPR] and the International Covenant on Economic, Social and 168 Cultural Rights [ICESCR], after which signatory countries were 169 required to reflect them in their national bodies of law. It is 170 also broadly recognized that not only states, but also non-state 171 actors must respect human rights. 173 Integrity The property that data has not been changed, destroyed, or 174 lost in an unauthorized or accidental manner [RFC4949]. 176 Linkability Establishing the identity of a host across several IP 177 addresses. 179 Open standards As stated in [RFC2026]: "Various national and 180 international standards bodies, such as ANSI, ISO, IEEE, and ITU- 181 T, develop a variety of protocol and service specifications that 182 are similar to Technical Specifications defined here. National 183 and international groups also publish "implementors' agreements" 184 that are analogous to Applicability Statements, capturing a body 185 of implementation-specific detail concerned with the practical 186 application of their standards. All of these are considered to be 187 'open external standards' for the purposes of the Internet 188 Standards Process." 190 Openness Absence of centralized points of control - "a feature that 191 is assumed to make it easy for new users to join and new uses to 192 unfold" [Ziewitzetal]. 194 Ossification The increasing inflexibility of the network which 195 results in the inability to deploy a new protocol or protocol 196 extensions due to the unchangeable nature of infrastructure 197 components that have come to rely on particular features of 198 current protocols. 200 Permissionless innovation The freedom and ability to freely create 201 and deploy new protocols on top of the communications constructs 202 that currently exist. 204 Privacy The right of an entity (usually an individual), acting on 205 its own behalf, to determine the degree to which it will interact 206 with its environment, including the degree to which the entity is 207 willing to share its personal information with others [RFC4949]. 209 The right of individuals to control or influence what information 210 related to them may be collected and stored, and by whom and to 211 whom that information may be disclosed. 213 Privacy is a broad concept regarding the protection of individual 214 or group autonomy and the relation between an individual or group 215 and society, including government, companies, and private 216 individuals. It encompasses a wide range of rights, including 217 protections from intrusions into family and home life, control of 218 sexual and reproductive rights, and communications secrecy. It is 219 commonly recognized as a core right that underpins human dignity 220 and other values such as freedom of association and freedom of 221 speech. The right to privacy is also recognized in nearly every 222 national constitution and in most international human rights 223 treaties. The right to privacy is also legally protected at the 224 national level through provisions in civil and/or criminal codes. 226 Pseudonymity The ability to use a persistent identifier that is not 227 immediately linked to an individual's offline identity. 228 Pseudonymity is an critical feature for many end users, as it 229 allows them different degrees of disguised identity and privacy 230 online. "Pseudonymity is strengthened when less personal data can 231 be linked to the pseudonym; when the same pseudonym is used less 232 often and across fewer contexts; and when independently chosen 233 pseudonyms are more frequently used for new actions (making them, 234 from an observer's or attacker's perspective, unlinkable)." 235 [RFC6973] 237 3. Review Methodology and Process 239 This section describes how the review was undertaken. 241 We started our review by examining the Internet Drafts which were 242 active on June 7, 2018 on the QUIC Working Group Datatracker 243 (https://datatracker.ietf.org/wg/quic/documents). 245 Inferential reading of the documents resulted in the decision to 246 focus our efforts on three specific drafts: draft-ietf-quic- 247 transport-12, draft-ietf-quic-tls-12, draft-ietf-quic-invariants-01. 249 From the study of these documents through the perspective of the 250 Guidelines for Human Rights Protocol Considerations outlined in 251 [RFC8280], we formulated a questionnaire, to be used as a tool to 252 guide semi-structured interviews with QUIC Working Group chairs and 253 document authors. 255 We engaged in a total of seven interviews, which took place during 256 IETF102 (July 14-20, 2018). These were then transcribed and 257 analyzed. The analysis focused on the identification of potential 258 positive or negative impacts on human rights, and on the 259 categorization of our findings according to the Guidelines for Human 260 Rights Protocol Considerations outlined in [RFC8280]. 262 One particular aspect that is critical to consider is the pace at 263 which the QUIC Working Group operates, which is regarded across the 264 IETF community as notably faster than usual. This means that while 265 the general design that is outlined in the QUIC Internet Drafts is 266 fairly stable, numerous details are in constant change. When it 267 comes to conducting an interview-based research, this also means that 268 some of the expressed points of view might be overtaken by 269 intervening changes. To address this specific characteristic of the 270 work on the QUIC protocol, we decided to set a time point to examine 271 active Internet Drafts and current Working Group discussions. The 272 time point is June 7, 2018. In addition to that, we also kept 273 discussing with the interviewees, reviewing notes from the following 274 New York interim meeting (September 19-20), and following selected 275 mailing list threads, until our final review of this very document, 276 on October 17, 2018. 278 The content examined until the set time point (June 7, 2018) is what 279 should be considered the core subject of our examination. However, 280 as we aim to helpfully contribute to the efforts of the QUIC Working 281 Group, we also decided to monitor potential updates and emerging 282 discussions which took place in the following months, with the aim to 283 provide relevant and applicable feedback. 285 4. Human Rights Considerations 287 The Human Rights Protocols Considerations Research Group (HRPC) 288 welcomes the drafts draft-ietf-quic-transport, draft-ietf-quic-tls, 289 draft-ietf-quic-invariants. 291 In particular, we welcome the efforts to improve connectivity on high 292 latency, low bandwidth and high loss connections, and the application 293 of encryption by default. Conclusions and recommendations can be 294 found at the end of this document. 296 No implications for Accessibility ([RFC8280], sec. 6.2.11), 297 Localization ([RFC8280], sec. 6.2.12), Decentralization ([RFC8280], 298 sec. 6.2.13), and Reliability ([RFC8280], sec 6.2.14) have been 299 found. 301 4.1. Connectivity 303 Overall, QUIC is expected to result in a greatly improved Internet 304 service for users worldwide, and in particular for those who 305 currently do not have high bandwidth or lossless connections. 306 Regions that currently do not benefit from reliable connectivity, 307 would be provided with a significantly improved service. These 308 advancements have positive implications in regards to human rights 309 such as freedom of expression, freedom of association, right to 310 political participation. 312 4.1.1. Latency 314 QUIC was designed as a new transport protocol to provide connections 315 with lower latency than previous protocols. 317 One of the most important differences between TCP and QUIC 318 connections is that QUIC connection establishment takes 0 RTTs when a 319 server is known by a client and up to a few RTTs for the first 320 connection to an unknown server. 322 By allowing for Zero-Round Trip Time (0-RTT) resumption of 323 connections, QUIC performs better than TCP on high latency and high 324 loss connections. When a web client uses TCP and TLS, it requires 325 two to three round trips with a server to establish a secure 326 connection before the browser can send a request. With QUIC, if a 327 client has communicated with a server before (within a specific time 328 period), it can start sending data without any round trips, so that 329 web pages will load faster. 331 An example of QUIC's performance can be observed on a well-optimized 332 site like Google Search, where connections are often pre-established, 333 and QUIC's faster connections can only speed up some requests. 334 Still, QUIC improves mean page load time by 8% globally, and up to 335 13% in regions where latency is higher. [Behretal] 337 4.1.2. Congestion Control and Loss Recovery 339 QUIC's congestion control is based on TCP NewReno [RFC6582], a 340 congestion window based congestion control. The signals QUIC 341 provides for congestion control are generic and are designed to 342 support different algorithms. In this way, QUIC can be configured to 343 fit best in different contexts. 345 Compared to TCP, QUIC offers more detailed feedback information for 346 loss detection. For example, it uses a monotonically increasing 347 packet number and does not retransmit on the packet-level but on the 348 content-level. This allows QUIC to distinguish retransmissions from 349 the originally sent packets, avoiding retransmission ambiguities. 351 Overall, comparing it to previously existing protocols, QUIC 352 implements better estimation of connection RTTs and detects and 353 recovers from loss more efficiently. 355 4.1.3. Reduced Head-Of-Line Blocking 357 HTTP/2 allows multiple objects to be fetched over the same 358 connection, using multiple streams within a single flow. 360 In TCP, if a loss occurs in one stream, all streams stall while 361 waiting for packet recovery. Differently, QUIC allows other streams 362 to continue to exchange packets even if one stream is blocked due to 363 a missing packet [MolaviKakhkietal]. 365 4.1.4. Resources 367 QUIC is relatively expensive to implement, both in terms of code 368 (size and complexity) and processing (including memory overheads). 369 This can represent a barrier to adoption and the benefits that come 370 with that. 372 4.2. Privacy 374 4.2.1. Encryption 376 QUIC incorporates the key negotiation features of TLS 1.3, requiring 377 all connections to be encrypted. 379 Encryption improves the security and privacy of user data. It is 380 built into QUIC, using AEAD algorithms such as AES-GCM and ChaCha20 381 for both privacy and integrity. QUIC authenticates the parts of its 382 headers that it does not encrypt, so attackers cannot modify any part 383 of a message [Behretal]. 385 Furthermore, in addition to improving privacy, encryption helps to 386 address the ossification of network protocols caused by middleboxes 387 that assume certain information to be present in the clear 388 [Kuehlewindetal]. 390 4.2.2. Transparent Proxying 392 Many cellular and high-latency networks use transparent TCP proxies 393 to reduce end-to-end delays and improve loss recovery. However, by 394 encrypting the transport headers, QUIC prevents transparent proxying, 395 thus protecting their integrity [MolaviKakhkietal]. 397 4.2.3. Multiple Streams 399 By establishing connection with multiple streams, QUIC creates higher 400 opacity for the observer. 402 Comparing QUIC to TLS over TCP, QUIC significantly reduces the amount 403 of information that an observer can acquire about communications they 404 are looking at. 406 In TCP, all of the information regarding the protocol flow at a 407 transport layer is exposed, and can be used to identify active 408 communications. 410 In QUIC, it is possible to have an established connection with an end 411 point and to run multiple streams over that connection. 412 Consequently, an observer who is looking at someone's connection, 413 would not be able to tell the difference between the streams. 415 4.2.4. Packet Number Encryption 417 In QUIC packet numbers are encrypted. 419 From a general standpoint, the number assigned to each packet carries 420 very little information. For example, it is possible to observe that 421 a packet sent a certain time and the packet that was sent immediately 422 after probably have increasing packet numbers. 424 But when traffic is carried over multiple paths, it becomes 425 observable at many points, and this has privacy implications. For 426 example, as stated in [draft-huitema-quic-mpath-req-01]: "[...] if 427 packets belonging to a given connection carry some unique 428 identifiers, observers could use these identifiers to track client 429 migrations through several paths, and thus potentially expose the 430 successive locations of a particular user." 432 4.2.5. Padding 434 Bit padding is the addition of one or more extra bits to a 435 transmission or storage unit to make it conform to a standard size. 437 QUIC (like HTTP/2 and TLS) offers a padding mechanism that can be 438 used as a defense against traffic analysis for protected packets. It 439 is important to note that its use is discretionary by 440 implementations. 442 4.2.6. Lawful Intercept 444 The lawful intercept of content in QUIC works similarly to TLS over 445 TCP. An intercept can: force the acceptance of an alternate 446 certificate; cooperate with or coerce the non-monitored endpoints to 447 obtain session keys for decryption of traffic; exploit endpoint 448 vulnerabilities to place monitoring devices directly on the endpoint 449 on the other side of the crypto boundary. 451 Forcing TLS 1.3 avoids some common exploit vectors in TLS 1.2 and 452 strengthens the ciphersuites. 454 4.2.7. Spin Bit 456 When Google offered the IETF the opportunity to take the work on QUIC 457 and produce an open standard that could be used by all [Wilketal], it 458 sparked off a debate within the IETF as to how much transport 459 information should be deliberately kept unknown to the network. 461 As an explicit design goal, QUIC provides far less information about 462 its operation to devices on path than TCP does. In TCP, the sequence 463 and acknowledgement numbers and timestamps (if the respective option 464 is in use) can be seen by on-path observers, and used to estimate 465 end-to-end latency. 467 Differently from previous transport protocols, QUIC splits the 468 information it uses for its own operation from its wire image. As a 469 consequence, QUIC's wire image currently does not expose any 470 information that can be used for passive latency measurement 471 techniques [draft-ietf-quic-spin-exp-00]. 473 At the June 2017 interim meeting of the QUIC Working Group, a 474 proposal was made to add a latency spin bit to QUIC's wire image, in 475 order to allow for passive measurability of RTT equivalent to TCP 476 [Trammell01]. 478 The spin bit is an explicit signal for passive measurability of 479 round-trip time. It causes one bit in the header to 'spin', 480 generating one edge (a transition from 0 to 1 or from 1 to 0) once 481 per end-to-end RTT. 483 During the following months, the proposal to add this facility to the 484 QUIC protocol has been further discussed and researched. At IETF101 485 the Working Group agreed upon the reservation of three bits for 486 experimentation with passive RTT measurement, with the result of this 487 experimentation to inform an eventual working group decision whether 488 to include the bit in the shipping version 1 of the protocol, 489 scheduled to be complete by November 2018. [Trammell02] 491 From its designers' perspective, the spin bit was formulated to be a 492 minimal-risk, maximum-utility signal fit for a single purpose: on- 493 path measurement of end-to-end RTT, to generate RTT samples for a 494 variety of passive latency measurement tasks. 496 The key argument in favor of the spin bit originates from the notion 497 that measurement is fundamental to the operation of networks and at- 498 scale services, whether for management, security, optimization, and 499 that if it is at all possible to safely design passive measurability 500 of any metric explicitly into a protocol, this signal represents how 501 to do it. [Trammell01] 503 The argument made by those who are not in favor of the addition of 504 the spin bit to the protocol, is that the exposure of any information 505 beyond the IP header and the base essentials of a UDP header is not 506 necessary and not safe. They point out that how this bit may be 507 used, were it to be added to the protocol, is unknown. 509 This could represent an infringement of the user privacy. 510 Furthermore, an exposed bit might cause for ossification of the bit 511 itself, which would, to some extent, defeat QUIC's efforts to elude 512 the intrusive and ossifying grip of network middleware. [Huston] 514 4.2.8. Packet Injection 516 It is viable for network operators to add data to packets in order to 517 do traffic monitoring and/or management. It is not uncommon for 518 network operators to routinely tag packets as they enter the network 519 for their own purposes, and simply erase the tag when they leave the 520 network. Packet modification or injection cannot be prevented in 521 QUIC. However, the protocol takes steps to ensure that its own state 522 is not affected by this kind of activity. 524 4.3. Content Agnosticism 526 The QUIC protocol itself is content agnostic. While it is currently 527 being optimized for HTTP traffic, it can also be used with other 528 application layer protocols (e.g. see 529 [draft-huitema-quic-dnsoquic-05]). 531 4.4. Security 533 QUIC improves security by making encryption an inherent part of the 534 transport protocol, instead of adding it as a optional layer on top 535 of it. This protects the integrity of the data by preventing 536 tampering on the path, and ensures end-to-end confidentiality between 537 the two communicating hosts. Furthermore, it ensure that no on-path 538 party can emulate an endpoint. 540 By encrypting all Internet traffic by default it is harder for 541 researchers and network operators to analyze network traffic. This 542 is a specific design goal, but it also makes research into the 543 promulgation of malware, cookies and other artefacts much harder, 544 since in this case access to the stream needs to be provided by the 545 end point. 547 4.5. Internationalization 549 [draft-ietf-quic-transport-12] does not define human readable 550 strings, except for where it states that the Reason Phrase in the 551 CONNECTION_CLOSE and APPLICATION_CLOSE frames "SHOULD be a UTF-8 552 encoded string [RFC3629]". The QUIC protocol demands that this 553 SHOULD be an UTF-8 string, while UTF-8 is actually not required. 554 Also, there is currently no space to declare the charset used. So it 555 is recommended that this SHOULD becomes a MUST. 557 [draft-ietf-quic-transport-12] does not allow for the use of language 558 tags. If it would request these tags, it would allow implementations 559 to signal in which language Reason Phrases are rendered. 561 4.6. Censorship Resistance 563 Encryption makes monitoring and filtering of the traffic more 564 complex, thus hindering fine-grained censorship. 566 Furthermore, in QUIC it is also harder to terminate connections, 567 since in the protocol the only parties that can terminate the 568 connection are those actually involved in the connection once it 569 exists. This means that a middlebox cannot reset a connection, but 570 needs to continue to block it, keeping state. Considering this, it 571 can be stated that QUIC makes censorship harder because it requires 572 the censor to invest more resources and efforts. 574 QUIC is also improving the protection against DDoS through 575 observation of the handshake for connection confirmation, and through 576 the need to validate new connections in case of a connection 577 migration. 579 It is worth noting that it is almost impossible to make the handshake 580 resilient to injection attacks, and the general consensus has been 581 not to spend cycles trying. This means that handshakes can easily be 582 disrupted by a censor. Post-handshake, QUIC is very resilient to 583 attempts to reset the connection by a third party. 585 4.7. Open Standards 587 QUIC is published as open standard. 589 4.8. Heterogeneity Support 591 The design of the QUIC transport protocol is currently specifically 592 tailored to be used with TLS1.3 and HTTP2. It is explicitly 593 constructed in a modular manner and is designed to support other 594 application layer protocols in the future as well. 596 4.9. Anonymity 598 Persistent static identifiers, consistently linking to a particular 599 person or small, well-defined group of people, are one of the main 600 threats to anonymity. This is especially concerning when the 601 identifier is used in repeatedly used in multiple contexts, thus 602 raising an issue of linkability. 604 In QUIC, linkability would occur in case a connection ID was used on 605 multiple network paths. In order to provide some protection against 606 linkability in case of connection migration, QUIC uses different 607 connection IDs when different local addresses are used. Furthermore, 608 packet numbers are encrypted to ensure they are not used to establish 609 a link between different connection IDs. 611 However, it is important to note that traffic analysis might still 612 allow to correlate different streams. 614 4.10. Pseudonymity 616 Keeping different identities isolated from each other is critical to 617 protect and preserve pseudonymity. QUIC contributes to this by using 618 different connections IDs for different local addresses. 620 4.11. Confidentiality 622 Through the use of cryptography, QUIC integrates security, 623 confidentiality, authenticity, and integrity directly into the 624 transport protocol rather than having them layered on top of it. Any 625 server that offers QUIC to benefit from its latency improvements will 626 automatically provide all the aforementioned attributes to their 627 user. 629 4.12. Integrity 631 The use of TLS1.3 in QUIC makes on-path attacks either visible or 632 nearly impossible to carry out. So, if an actor forces the traffic 633 to go through one middlebox and decrypt the traffic itself, their 634 action is made detectable. This also protects the integrity of the 635 datastream, prevents tampering, and averts the injection of extra 636 data in the stream. 638 4.13. Authenticity 640 Except for the initial handshake, the encryption in QUIC is provided 641 by TLS1.3, which uses asymmetric cryptography to authenticate the 642 hosts. This enables verification of authenticity. 644 4.14. Adaptability 646 QUIC has a modular approach, and is designed for adaptation. The 647 only commitments in the protocol are the requirement to run on UDP, 648 the packet header, and the version negotiation phase. The remainder 649 of the protocol is quite flexible and can be further adapted. 651 By preventing the ossification of the protocol by middleboxes through 652 the encryption of transport headers, QUIC enhances the adaptability 653 of the architecture. 655 As a transport protocol, QUIC tries to be agnostic for application 656 layer protocols, even though it is currently tailored to work with 657 HTTP/2. 659 4.15. Outcome Transparency 661 Outcome transparency concerns the intelligibility of the effects of a 662 protocol in relation to its users, protocol developers, and 663 implementers, and its potential consequences (e.g. lack of 664 authenticity may lead to lack of integrity and negative 665 externalities)[RFC8280]. 667 QUIC represents a remarkable evolution of the transport layer with 668 significant impact on the Internet architecture and, most 669 importantly, the service provided to users. 671 4.15.1. Encryption 673 The IETF has reached consensus on the fact that pervasive monitoring 674 is an attack (see [RFC7258]), and that a response to mitigate this is 675 represented by ubiquitous encryption, which would also reinforce the 676 end-to-end nature of the network [RFC2775] [RFC3724] [RFC7754]. 678 With the advent of QUIC, encryption becomes the default on the 679 transport level. This has a critical impact on the protection of 680 user privacy. 682 Furthermore, it has implications concerning network operators that 683 had previously used visible parts of protocols to, among other 684 things, manage, operate, and secure their networks [RFC8404]. 686 Encryption also improves the integrity of the datastream, as QUIC 687 allows to protect users against injections of ads by network 688 operators. 690 4.15.2. Permissionless Innovation and Its Challenges 692 As suggested by interviewees during the research phase of this 693 review, and to acquire a more contextualized understanding of 694 protocol development efforts over time, it is relevant to pay 695 attention to the history of SCTP (Stream Control Transmission 696 Protocol). SCTP is a protocol for transmitting multiple streams of 697 data at the same time between two end points that have established a 698 connection in a network, standardized in [RFC4960]. 700 As outlined in the comparison between SCTP and QUIC presented in 701 [draft-joseph-quic-comparison-quic-sctp-00], the deployment of SCTP 702 is not particularly widespread. In-network devices, like NAT 703 gateways for example, do not support SCTP well. NAT gateways need to 704 be upgraded to be SCTP-aware, the modification of middleboxes is very 705 expensive, and Internet service providers, focusing on the 706 sustainability of their business, update the devices in accordance 707 with the benefit that this can represent for their revenues. 709 Furthermore, an early version of QUIC (now popularly called gQUIC) 710 was initially designed and deployed by a large content provider, 711 Google. It was implemented in 2012, and the company invested 712 significant resources to develop it, for example conducting thorough 713 A/B-testing in order to assess how the protocol would interact with 714 the network, and how the middleboxes would respond. QUIC is now 715 widely used in Chrome clients accessing Google services. 717 In 2015, an Internet Draft of a specification for QUIC was submitted 718 to the IETF for standardization, and the following year the QUIC 719 Working Group was established. A growing number of contributors from 720 the corporate, academic, nonprofit sector have joined the protocol 721 development work since, and what has been achieved to date is the 722 result of a notable and labor-intensive collaborative effort. 724 So, on one hand, the history of QUIC shows that permissionless 725 innovation is still possible. On the other hand, it also shows what 726 remarkable efforts and resources are needed to carry out such an 727 ambitious project. While permissionless innovation still exists, the 728 threshold and costs for innovation seem to rise significantly and 729 increasingly. 731 Also, a look at the actors and dynamics involved in QUIC's history 732 should not underestimate the power of Google's authority. A 733 different developing actor might have been able to invest a similar 734 amount of resources into the development of a protocol. Still, 735 without an impressive user base and traffic stream as Google's, they 736 might have received a less supportive response from network 737 operators. 739 Having said that, it is expected that QUIC will improve the current 740 situation by providing a more capable transport which aims to 741 overcome ossification and allow for changes in the protocol due to 742 its modularity. 744 4.15.3. Privacy, Power and Consolidation 746 The most relevant privacy advantage provided by QUIC is gained by 747 users who have different kinds of traffic relations with one end 748 point. In fact, QUIC does not allow network providers to easily 749 differentiate between, for instance, HTTP requests, DNS requests and 750 real time voice packets, thus strengthening user privacy, and also 751 improving performance. It is important to note, though, that QUIC 752 does not actually hide or attempt to hide the application protocol 753 being used on a connection. The ALPN offered by the client is 754 protected only by a key which can be calculated by any party who can 755 work with the QUIC version in use. 757 On the other hand, this creates a concentration of different kinds of 758 traffic with one end point, thus giving the service provider access 759 to more categories of privacy sensitive information. 761 In the current reality of the Internet, the biggest hosts are 762 controlled by large, consolidated, transnational corporations. This 763 creates an extreme power differential between end users on the one 764 hand, and service providers and content operators on the other hand. 766 In order to protect privacy and secure information, it is important 767 that the user makes a careful and informed decision about the hosting 768 provider and plan they choose. 770 While ubiquitous encryption changes the relation between service 771 providers and content operators, placing them at the same end of the 772 spectrum, it remains to be seen whether if it can help users take and 773 retain control within the overall power structures of Internet 774 governance and economics. 776 One of the problems with deploying fully encrypted protocols like 777 QUIC is that deployment is far easier for organizations that already 778 have integrated observability, traceability, and tooling in their 779 back-ends, which not surprisingly happen to be the big players. 781 If there was any chance to make running a QUIC server relatively 782 easy, thus enabling a greater diversification of end points, QUIC 783 could contribute to a power shift in favor of the end user. 785 However, running a QUIC infrastructure is currently expected to be 786 more demanding than running a HTTP/2 or HTTP/1 infrastructure. It 787 would be truly compelling if this consideration could be discussed 788 further, and ideally addressed by the development and release of 789 openly available tooling allowing for more accessible ways to run a 790 QUIC server. 792 4.15.4. Transparency and IoT 794 End-to-end encryption on the transport layer makes monitoring and 795 filtering of the traffic more complex, and can lead to the adoption 796 of other network management practices to obtain this information. 798 This has implications on the management of Internet of Things (IoT) 799 devices. If an IoT device adopts QUIC, it will be harder for the 800 user who owns the device to monitor what data is communicated with 801 third parties. It would also be more difficult to conduct research 802 into the promulgation of malware, cookies and other artefacts. 804 Adequate tooling to protect the right to privacy of IoT users has not 805 yet been developed. 807 5. Conclusions and Recommendations 809 The QUIC protocol provides significant human rights improvements for 810 end users. 812 It dramatically improves connectivity for users on high-loss, high- 813 latency connections. Users will benefit from lower latencies and 814 will not need to restart sessions as often. And in those cases in 815 which they will need to restart a session, they will able to do so 816 without having to re-do the initial handshake. 818 Another key improvement is represented by the use of encryption by 819 default, which provides authentication, stream integrity, 820 adaptability of the protocol by overcoming ossification, and improved 821 protection from third party monitoring and metadata analysis. 823 The following is a list of potential improvements that we invite the 824 QUIC Working group to take into consideration, wishing for the 825 protocol to have even greater positive implications for human rights. 827 - As the QUIC Working Group is expected to deliberate on the 828 potential inclusion of the spin bit in the main specification of 829 the protocol at the upcoming IETF103 (November 3-9, 2018), we 830 suggest to consider not to include it. Our recommendation is 831 motivated by the concerns raised in regards to its implications on 832 user privacy, as reported in this very document, and also shared 833 by some of the interviewees. 835 - Consider deploying IP header encryption as an optional extension. 837 - Evaluate the addition of language tagging and charset 838 identification in the case of Reason Phrase in the 839 CONNECTION_CLOSE and APPLICATION_CLOSE. 841 - Examine the opportunity to translate the QUIC specification into 842 other languages. 844 - Discuss the viability to make tooling for running QUIC servers 845 openly available. 847 - Observe and iteratively assess the implications of QUIC on the 848 power relations between end user on one end of the spectrum, and 849 network operators and service providers on the other one. 851 6. Acknowledgements 853 The authors thank (in alphabetical order) Mike Bishop, Janardhan 854 Iyengar, Daniel Kahn Gillmor, Mirja Kuehlewind, Mark Nottingham, 855 Martin Thomson, and Brian Trammell for their generous contribution to 856 our research and review. This document does not necessarily reflect 857 their opinion, but solely that of the authors. 859 7. Security Considerations 861 As this draft concerns a research document, there are no security 862 considerations. 864 8. IANA Considerations 866 This document has no actions for IANA. 868 9. Review Team Information 870 The discussion list for the Human Rights Review Team is located at 871 the e-mail address hr-rt@irtf.org [1]. Information on the group and 872 information on how to subscribe to the list is at 873 https://www.irtf.org/mailman/listinfo/hr-rt [2] 875 Archives of the list can be found at: https://www.irtf.org/mail- 876 archive/web/hr-rt/current/index.html [3] 878 10. References 880 10.1. Informative References 882 [Behretal] 883 Behr, M. and I. Swett, "Introducing QUIC Support for HTTPS 884 Load Balancing", June 2018, 885 . 888 [Cuietal] Cui, Y., Li, T., Liu, C., Wang, X., and M. Kuehlewind, 889 "Innovating Transport with QUIC: Design Approaches and 890 Research Challenges", IEEE Internet Computing, Vol 21(2), 891 pp. 72-76 , March 2017, . 894 [draft-huitema-quic-dnsoquic-05] 895 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 896 Iyengar, "Specification of DNS over Dedicated QUIC 897 Connections (work in progress)", June 2018, 898 . 901 [draft-huitema-quic-mpath-req-01] 902 Huitema, C., "QUIC Multipath Requirements (work in 903 progress)", January 2018, . 906 [draft-ietf-quic-invariants-01] 907 Thomson, M., "Version-Independent Properties of QUIC (work 908 in progress)", March 2018, . 911 [draft-ietf-quic-spin-exp-00] 912 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin Bit 913 (work in progress)", April 2018, 914 . 916 [draft-ietf-quic-tls-12] 917 Thomson, M. and S. Turner, "Using Transport Layer Security 918 (TLS) to Secure QUIC (work in progress)", May 2018, 919 . 921 [draft-ietf-quic-transport-12] 922 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 923 and Secure Transport (work in progress)", May 2018, 924 . 927 [draft-joseph-quic-comparison-quic-sctp-00] 928 Joseph, A., Li, T., He, Z., Cui, Y., and L. Zhang, "A 929 Comparison Between SCTP and QUIC (work in progress)", 930 March 2018, . 933 [FIArch] Future Internet Architecture (FIArch) Group, "Future 934 Internet Design Principles", January 2012, . 938 [Gratzer] Gratzer, F., ""QUIC - Quick UDP Internet Connections"", 939 Seminar Innovative Internet-Technologien und 940 Mobilkommunikation SS2016 , 2016, 941 . 944 [Halletal] 945 Hall, J., Aaron, M., and B. Jones, "A Survey of Worldwide 946 Censorship Techniques (work in progress)", April 2015, 947 . 950 [Huston] Huston, G., "Just One QUIC Bit", APNIC , March 2018, 951 . 953 [ICCPR] United Nations General Assembly, "International Covenant 954 on Civil and Political Rights", December 1966, 955 . 958 [ICESCR] United Nations General Assembly, "International Covenant 959 on Economic, Social and Cultural Rights", December 1966, 960 . 963 [Kuehlewindetal] 964 Kuehlewind, M., Buehler, T., Trammell, B., Neuhaus, S., 965 Muentener, R., and G. Fairhurst, "A Path Layer for the 966 Internet: Enabling Network Operations on Encrypted 967 Protocols", IEEE International Conference on Network and 968 Service Management (CNSM) , November 2017, 969 . 972 [MolaviKakhkietal] 973 Molavi Kakhki, A., Jero, S., Choffnes, D., Nita-Rotaru, 974 C., and A. Mislove, "Taking a Long Look at QUIC", 975 Proceedings of IMC '17, London, United Kingdom , November 976 2017, . 979 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 980 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 981 . 983 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 984 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 985 . 987 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 988 DOI 10.17487/RFC2775, February 2000, 989 . 991 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 992 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 993 2003, . 995 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 996 the Middle and the Future of End-to-End: Reflections on 997 the Evolution of the Internet Architecture", RFC 3724, 998 DOI 10.17487/RFC3724, March 2004, 999 . 1001 [RFC4084] Klensin, J., "Terminology for Describing Internet 1002 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 1003 May 2005, . 1005 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1006 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1007 . 1009 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1010 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1011 . 1013 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 1014 NewReno Modification to TCP's Fast Recovery Algorithm", 1015 RFC 6582, DOI 10.17487/RFC6582, April 2012, 1016 . 1018 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1019 Morris, J., Hansen, M., and R. Smith, "Privacy 1020 Considerations for Internet Protocols", RFC 6973, 1021 DOI 10.17487/RFC6973, July 2013, 1022 . 1024 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1025 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1026 2014, . 1028 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1029 Nordmark, "Technical Considerations for Internet Service 1030 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1031 March 2016, . 1033 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1034 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1035 October 2017, . 1037 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 1038 Pervasive Encryption on Operators", RFC 8404, 1039 DOI 10.17487/RFC8404, July 2018, 1040 . 1042 [Trammell01] 1043 Trammell, B., "Explicit Passive Measurability and the QUIC 1044 Spin Bit", APNIC , May 2018, 1045 . 1048 [Trammell02] 1049 Trammell, B., "And Yet, It Spins", March 2018, 1050 . 1052 [UDHR] United Nations General Assembly, "The Universal 1053 Declaration of Human Rights", December 1948, 1054 . 1056 [Wilketal] 1057 Wilk, A., Hamilton, R., and I. Swett, "A QUIC Update on 1058 Google's Experimental Transport", April 2015, 1059 . 1062 [Ziewitzetal] 1063 Ziewitz, M. and I. Brown, "A Prehistory of Internet 1064 Governance", Research Handbook on Governance of the 1065 Internet, ed I. Brown, 3-26. Cheltenham: Edward Elgar , 1066 2013. 1068 10.2. URIs 1070 [1] mailto:hr-rt@irtf.org 1072 [2] https://www.irtf.org/mailman/listinfo/hr-rt 1074 [3] https://www.irtf.org/mail-archive/web/hr-rt/current/index.html 1076 Authors' Addresses 1077 Beatrice Martini 1078 Harvard Kennedy School 1080 EMail: mail@beatricemartini.it 1082 Niels ten Oever 1083 University of Amsterdam 1085 EMail: mail@nielstenoever.net