idnits 2.17.1 draft-andersdotter-rrm-for-rrt-in-http3-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D-QUIC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 521 == Missing Reference: '-k' is mentioned on line 478, but not defined == Missing Reference: '-2' is mentioned on line 519, but not defined == Missing Reference: '-1' is mentioned on line 519, but not defined -- Looks like a reference, but probably isn't: '1' on line 519 -- Looks like a reference, but probably isn't: '2' on line 519 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force A. Andersdotter 3 Internet-Draft ARTICLE 19 4 Intended status: Informational S. Sahib 5 Expires: May 6, 2020 Salesforce 6 November 3, 2019 8 Randomized Response Mechanisms in RRT Measurements for HTTP/3 9 draft-andersdotter-rrm-for-rrt-in-http3-00 11 Abstract 13 The latency spin bit is an optional feature included in the QUIC 14 transport protocol [I-D-QUIC]. It enables passive, on-path 15 observations for estimation of latency. This document presents the 16 results of an inquiry into the potential of using randomized response 17 mechanisms (RRM) to reduce privacy loss in latency measurements. It 18 concludes that RRM could be used to introduce choice for clients in 19 preserving privacy in latency measurements. But the trade-offs, 20 especially since the latency spin bit is already optional, do not 21 favour RRM. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 6, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Randomized Response Mechanisms . . . . . . . . . . . . . . . 2 59 3. Application to latency spin bit . . . . . . . . . . . . . . . 3 60 3.1. RRM at edge transition . . . . . . . . . . . . . . . . . 6 61 3.1.1. No reset and no edge identifying bit . . . . . . . . 7 62 3.1.2. Reset and no edge identifying bit . . . . . . . . . . 8 63 3.1.3. An edge identifying bit . . . . . . . . . . . . . . . 9 64 3.1.4. Discussion . . . . . . . . . . . . . . . . . . . . . 10 65 3.2. RRM at each bit . . . . . . . . . . . . . . . . . . . . . 10 66 3.2.1. Client perturbation . . . . . . . . . . . . . . . . . 11 67 3.2.2. Client and server perturbation . . . . . . . . . . . 12 68 3.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . 12 69 4. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6. Informative References . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 At the IETF104 convening of the Privacy Enhancements and Assessments 77 Research Group (PEARG), a presentation on Differential Privacy 78 ([AA-CL]) gave rise to the idea of trying to apply Randomized 79 Response methods to the QUIC Spin Bit described in [TRAMMEL] and 80 [KUEHLEWIND]. Now incorporated in Section 17.3.1 [I-D-QUIC], the 81 latency spin bit has generated controversy from a privacy 82 perspective, both in the Working Group meetings and on e-mailing 83 lists. Controversies were re-ignited through the publication of a 84 Human Rights Consideration in [TENOEVER-MARTINI]. Applying RRM is an 85 attempt to address two problems: the privacy loss incurred through 86 the spin bit, and considering the potential of using RRM to have more 87 than one bit assisting in latency measurement as per previous 88 proposals. 90 2. Randomized Response Mechanisms 92 Randomized Response Mechanisms (RRM) rely on the ability to make 93 sense of data with known errors and were originally developed to 94 facilitate surveys on sensitive topics such as alcohol or drug abuse 95 or political affiliation. The design allows a survey taker to 96 provide, with some known probability P, a "false" answer ("yes" 97 instead of "no", for example) to a survey question. It is meant to 98 encourage truthful answers even in surveys where participants may 99 otherwise feel compelled to give false answers. 101 Randomized response trials were originally created for binary 102 environments: if a series of measurements have only two possible 103 outcomes (0 or 1, yes or no, true or false, for instance), it is the 104 idea that allowing individual respondents to answer "falsely" at a 105 predictable rate will still preserve the ability to make inferences 106 on the entire set of respondents. The latency spin bit, being a bit, 107 is binary outcome variable. Each time it is measured, the idea is 108 that it can either "truthfully" report its value as what it should be 109 according to [TRAMMEL], or it could, at some known rate or 110 probability, report the opposite value. 112 RRMs are easily illustrated for binary response problems. Let's take 113 as an example "Did you go to the last IETF meeting?" The answer to 114 this question is either yes or no. Let us suppose that 25% of all 115 responses are known to be false, and that 80% of all respondents 116 answered yes. Then 60% of the respondents who answered yes can be 117 assumed to have done so truthfully, while 5% of the respondents who 118 answered no have done so falsely. 65% of the respondents can 119 therefore be estimated to have actually attended the last IETF 120 meeting. 122 RRMs can also be applied to multiple choice questions. Estimation of 123 true proportions becomes more difficult as the number of possible 124 answers per question goes up. Further examples, including formulas 125 and calculations, can be found in [DWORK] and [FOX]. 127 3. Application to latency spin bit 129 As described in [TRAMMEL], the latency spin bit is a mechanism for 130 measuring round-trip-times (RTT) in the QUIC protocol. The 131 investigation in this document relies on [TRAMMEL] for its 132 understanding of the basic operation of the latency spin bit, and in 133 particular the following paragraphs and figures from the document are 134 quoted to facilitate the description of RRM below: 136 [Begin quote] Initially, during connection establishment, no packets 137 with a spin bit are in flight, as shown in Figure 1. 139 +--------+ - - - - - +--------+ 140 | | --------> | | 141 | Client | | Server | 142 | | <-------- | | 143 +--------+ - - - - - +--------+ 145 Figure 1: Initial state, no spin bit between client and server 147 Either the server, the client, or both can begin sending packets with 148 short headers after connection establishment, as shown in Figure 2; 149 here, no spin edges are yet in transit. 151 +--------+ 0 0 - - - +--------+ 152 | | --------> | | 153 | Client | | Server | 154 | | <-------- | | 155 +--------+ - - 0 0 0 +--------+ 157 Figure 2: Client and server begin sending packets with spin 0 159 Once the server's first 0-marked packet arrives at the client, the 160 client sets its spin value to 1, and begins sending packets with the 161 spin bit set, as shown in Figure 3. The spin edge is now in transit 162 toward the server. 164 +--------+ 1 0 0 0 0 +--------+ 165 | | --------> | | 166 | Client | | Server | 167 | | <-------- | | 168 +--------+ 0 0 0 0 0 +--------+ 170 Figure 3: The bit begins spinning 172 Five ticks later, this packet arrives at the server, which takes its 173 spin value from it and reflects that value back on the next packet it 174 sends, as shown in Figure 4. The spin edge is now in transit toward 175 the client. 177 +--------+ 1 1 1 1 1 +--------+ 178 | | --------> | | 179 | Client | | Server | 180 | | <-------- | | 181 +--------+ 0 0 0 0 1 +--------+ 183 Figure 4: Server reflects the spin edge 185 Five ticks later, the 1-marked packet arrives at the client, which 186 inverts its spin value and sends the inverted value on the next 187 packet it sends, as shown in Figure 5. 189 obs. points X Y 190 +--------+ 0 1 1 1 1 +--------+ 191 | | --------> | | 192 | Client | | Server | 193 | | <-------- | | 194 +--------+ 1 1 1 1 1 +--------+ 195 Y 197 Figure 5: Client inverts the spin edge 199 [End quote] 201 In each iteration going from Figure 4 to Figure 5 a sequence of 0s or 202 1s the length of which is k0 for iteration 0, k1 for iteration 1, and 203 so forth, can be observed (by on-path observers X or Y in Figure 5). 204 The length of each sequence equals the amount of ticks required to 205 pass from the client back to the client. After observation n lengths 206 of such sequences, (k[0], ..., k[n]), an average can be taken over 207 k[j]. This average can be multiplied by the amount of time per tick 208 (a quantity which is assumed to be known) to get a value for the 209 round-trip time (RTT). 211 Applying randomized response mechanisms (RRMs) perturbs the observed 212 sequence lengths (k[0], ..., k[n]). The perturbation will have the 213 effect of lengthening, shortening, or making more arbitrary the 214 lengths of the sequences, thereby increasing the variance, or disable 215 the possibility, of an estimator of the true RTT value. 217 The server or the client is assumed to behave as described in 218 Figure 4 and Figure 5, unless specifically stated otherwise. That 219 means the assumed default behaviour is that a "truly" reflecting 220 server that receives a bit set to v=0 always reflects a bit with v=0. 221 In an RRM application, a server which "falsely" reflects a bit 222 receives a bit set to v=0 and reflects a bit set to v=1. Similarly, 223 the assumed default behaviour of a client is that it "truly" inverts 224 a bit, so that receiving a bit set to v=0 causes it to transmit a bit 225 set to v=1. In an RRM application, the client may "falsely" transmit 226 a bit set to v=0 even when it has received a bit set to v=0. The 227 receiving of a spin edge is assumed to be a trigger event for a 228 reflection or an inversion. The server and the client are assumed to 229 have an internal spin value that determines the spin bit that goes 230 out. Every time a spin edge comes in (a trigger), this internal spin 231 value is changed, changing also the outgoing spin value. 233 An additional assumption is that the server and client behave 234 independently of one another. This means that the server has no 235 information on whether the client has omitted an inversion, and the 236 client has no information on whether the server has omitted a 237 reflection. Omissions are therefore independent events. 239 We have looked at two ways of perturbing measurements: 241 1. RRMs are applied so that edge transitions do not occur with 242 probability P or Q for server and client respectively. 244 2. RRMs are applied so that that each bit transmitted, whether or 245 not an inversion is occurring, has a probability P of being the 246 "wrong" value. 248 They will be dealt with in turn, identifying pitfalls and potential 249 ways of addressing those pitfalls. The goal is to have better 250 privacy-protecting properties while continuing to allow utility of 251 the on-path observations in latency measurements. 253 3.1. RRM at edge transition 255 The omission of a reflection or inversion creates difficulties. 256 Namely, let's say the client omits the inversion in Figure 5. Now 257 there is no longer a spin edge so there is nothing to activate future 258 reflections/inversions. 260 A possible work-around is to do random re-sets of the spin bit, i.e., 261 starting the process fresh from Figure 2. Observers X and Y in 262 Figure 5 would then get a series of measurements (k0, ..., kn), some 263 of which were far too large, but would, over time, be able to deduce 264 RTT from the smaller measurements. The expected proportion of large 265 and small measurements in the whole set of measurements could be 266 determined from the probabilities that a edge transition does not 267 happen and the probability that the spin bit is re-initiated. 269 Another possible work-around is having an additional bit to indicate 270 a spin edge, assigned by the server to the bit which is (not) 271 reflected in Figure 4, or by the client to the bit which is (not) 272 inverted in Figure 5. In this case there would not be a point in 273 applying RRM since the placement of the spin edge would no longer be 274 obfuscated. 276 If the ordinary spin edge is obfuscated by through omission of edge 277 transition, and the edge-identifying bit is also, with some 278 probability, not correctly identifying an edge, the utility of having 279 two latency bits again goes up at no additional loss of privacy. 281 3.1.1. No reset and no edge identifying bit 283 The bit starts spinning with value v=1 in Figure 3. At the point of 284 reflection (see Figure 4), it does not reflect with probability P. 285 At the point of inversion (see Figure 5), it does not invert with 286 probability Q. We consider P and Q respectively to be the 287 probability that the server or client does not behave in the way 288 specified. 290 Let -> be the operation that a bit changes value. A correct 291 reflection will be denoted R: a->a. A correct inversion is denoted 292 I:a->b. Prefixing R or I with a ! denotes that edge transition was 293 not done correctly. The variables a and b assume the values 0 or 1 294 and are never equal. P(R: a->a) = 1-P and P(I: a->b) = 1-Q, while 295 P(!R: a->b) = P and P(!I: a->a) = Q. An expression like R(v: 1->1) 296 -> !I(v: 1->1) means that a bit whose initial value is 1 is correctly 297 reflected, and then incorrectly inverted. We can abbreviate this to 298 [1->1->1]. R must follow I and vice versa, so we will have a chain 299 of events R->I->R->I-> etc. 301 In order for a reflection or an inversion to occur, there must be a 302 trigger. The spin edge is the trigger. But in the event of 303 [1->1->1] the spin edge has disappeared! Once the bit spins back to 304 the reflection, it will have the same value as when it started. In 305 fact, regardless of the starting value, any R->I event that results 306 in [1->1] or [0->0] leads to a loop. 308 We can define the following events: 310 A: [1->1]. 312 B: [0->0]. 314 C: [0->1]. 316 D: [1->0]. 318 Event A can occur as a result of (!R, !I) for starting point v=0, or 319 as a result of (R, !I) for starting point v=1 or v=0. Event B can 320 occur as a result of (!R, !I) for starting point v=1, or as a result 321 of (R, !I) for starting point v=1 or v=0. Event C occurs as a result 322 of (!R, I) for starting point v=1, or (R, I) for starting point v=0. 323 Event D occurs as a result of (!R, I) for starting point v=0 or (R, 324 I) for starting point v=0. The starting point v can be taken as the 325 final digit in each event, meaning that for the event following C, 326 the starting point would be v=1, and for the event following D, the 327 starting point would be v=0. 329 With this information, and the probabilities determined above, we can 330 create a transition matrix in the Markovian sense. 332 +----+-----------+-----------+-----------+-----------+ 333 | | A | B | C | D | 334 +----+-----------+-----------+-----------+-----------+ 335 | A | 1 | 0 | 0 | 0 | 336 +----+-----------+-----------+-----------+-----------+ 337 | B | 0 | 1 | 0 | 0 | 338 +----+-----------+-----------+-----------+-----------+ 339 | C | (1-P)Q | Q | P(1-Q) | (1-P)(1-Q)| 340 +----+-----------+-----------+-----------+-----------+ 341 | D | Q | (1-P)Q |(1-P)(1-Q) | P(1-Q) | 342 +----+-----------+-----------+-----------+-----------+ 344 Figure 6: RRM transition matrix, no reset and no edge-id bit 346 It should be quite clear from this matrix that events A and B act as 347 sinks. Because ending in a sink removes all possibility of future 348 measurements, we could hope to avoid this situation. The easiest way 349 is setting Q=0, which would imply there is always a correct 350 inversion. For any Q > 0, this process will eventually end up in a 351 sink. 353 3.1.2. Reset and no edge identifying bit 355 The possible outcomes are as in Section 3.1.1, and the problem to be 356 resolved is that the spin edge eventually disappears with probability 357 1. 359 Introducing the probability R of a random re-set of the spin bit at 360 every m:th bit transmission can "re-initiate" the edge by taking the 361 entire system back into the situation described in Figure 4 (with the 362 modification that it is not assumed that the starting point must be 363 v=1; the starting point could also be reset to v=0). It is assumed 364 that a re-set occurs on the client-side, and not on the server-side. 366 The true number of ticks in a round-trip time is C. If R>0 and m >> 367 C, the process will be reset every period of km ticks, where k is an 368 integer whose distribution is geometric with parameter R. After km 369 ticks, an on-path observer may pick up a sequence that can be used as 370 a basis for measuring the round-trip time. 372 In Figure 7 the situation where m=2 is illustrated. 374 +---+----------+--------+----------+--------+----------+----------+ 375 | | A,m0 | A,m1 | B,m0 | B,m1 | C | D | 376 +---+----------+--------+----------+--------+----------+----------+ 377 |A,0| 0 | 1 | 0 | 0 | 0 | 0 | 378 +---+----------+--------+----------+--------+----------+----------+ 379 |A,1| 1-R | 0 | 0 | 0 | R | 0 | 380 +---+----------+--------+----------+--------+----------+----------+ 381 |B,0| 0 | 0 | 0 | 1 | 0 | 0 | 382 +---+----------+--------+----------+--------+----------+----------+ 383 |B,1| 0 | 0 | 1-R | 0 | R | 0 | 384 +---+----------+--------+----------+--------+----------+----------+ 385 | C | (1-P)Q | 0 | Q | 0 | P(1-Q) |(1-P)(1-Q)| 386 +---+----------+--------+----------+--------+----------+----------+ 387 | D | Q | 0 | (1-P)Q | 0 |(1-P)(1-Q)| P(1-Q) | 388 +---+----------+--------+----------+--------+----------+----------+ 390 Figure 7: RRM TM, Reset at m=2, no edge-id bit 392 If m (or km | k ~ Ge(R)) is too small, there will never be any sound 393 measurements since the process will always start over before a 394 measurement appears. Using a reset function is therefore especially 395 burdensome for an on-path observer in cases where latencies are a 396 priori expected to be large. 398 3.1.3. An edge identifying bit 400 The possible outcomes are as in Section 3.1.1, and the problem to be 401 resolved is that the spin edge eventually disappears with probability 402 1. 404 Introducing an edge identifying bit, which may or may not hold a true 405 value with probability S, could help mitigate this problem. This 406 could effectively be seen as a recursive RRM: because the original 407 RRM risks removing the utility of the spin bit entirely, another bit 408 to which RRM is applied is added. 410 Logically, adding another identifying bit increases the possible set 411 of states of the Markovian chains described in Section 3.1.1 and 412 Section 3.1.2. In fact, the systems would still possess similar 413 short-comings, but with different probabilities. The exception is if 414 the identifying bit is always on with probability S=1. In this case, 415 the privacy-enhancing properties sought in Section 3.1.1 and 416 Section 3.1.2 would be lost, since the main goal of RRM in both of 417 those cases is to perturb the measurements (k0, ...., kn) used to 418 estimate round-trip times. 420 3.1.4. Discussion 422 In Section 3.1.1 we saw that applying RRM at reflection and inversion 423 could create a situation where the spin edge disappears. There are 424 two parameters, P and Q, which are set by the client and server 425 respectively. 427 We could reduce the risk of the spin edge disappearing by setting the 428 probability of a wrongful inversion to Q=0. However, inversion is an 429 activity undertaken by the client and Q is a parameter under the 430 clients control. Since the client is the entity assumed, in most 431 cases, to be the most likely actor to be a human, natural person (in 432 either case, more likely than the server), this solution would remove 433 power from the client. Forcibly setting Q=0 would violate the 434 assumptions of user control in Section 7.2 [RFC6973]. 436 In Section 3.1.2 we considered whether it was possible to reset a 437 latency spin bit whose edge has disappeared. Effectively, resetting 438 would improve an on-path observers chances of making measurements, 439 but it also introduces a delay for the acquisition of useful 440 measurements. 442 We assume that the client will set Q>0 and that this is under the 443 client's control, and have three additional parameters: P, m and R. 444 Both m and R can be under the client's control. We found that km | 445 k~Ge(R) has an impact on the ability to measure latency when latency 446 is large. In practice, an average human, natural person is probably 447 not going to choose parameters Q, m and R (even though they could be 448 made available at settings in an interface). Setting of these 449 parameters will instead likely be under the control of the entity 450 that produces latency spin bit capable software. 452 In Section 3.1.3 we conclude that adding an edge-identifying bit is 453 not a remedy to any of the issues with the methods in Section 3.1.1 454 or Section 3.1.2. It introduces the possibility of yet another 455 client-controlled parameter S, but the obfuscating effects derived 456 from S could instead be obtained by regulating previously suggested 457 parameters Q, m or R. 459 3.2. RRM at each bit 461 Let us say any bit transmitted from either the client or the server 462 is "off" in relation to what it proposed in the Spin Bit model with 463 some probability Q. If Q = 0.5, the spinning bits will come across 464 as a random 0s and 1s and it will be difficult to estimate any edge. 465 However, if Q is less than 0.5, the spin edge can be estimated for 466 instance by computing an average number of 0s or 1s in the past m 467 ticks. For all averages above some cut-off rate, a measurement 468 counter could be incremented by one. Eventually one would end up 469 with a series (k'0, ..., k'n) that roughly corresponds to (k0, ..., 470 kn) above. 472 3.2.1. Client perturbation 474 The bit spins in the foreseen way. Every time a bit is transmitted, 475 there is a probability Q that it holds a different value than it 476 should. In Figure 5 , either measurements station X or both stations 477 Y observe a passing bit, as well as bits passing before or after that 478 bit (if any). After observing 2k+1 bits (b[-k], ..., b[0], ..., 479 b[k]) the true value of bit b[0] is estimated, for instance based on 480 whether the majority of b[i] were v=0 or v=1. The estimated value is 481 then used to increment a sequence counter. 483 The estimator follows a binomial distribution (drawing with 484 replacement), and the risk of misidentifying a bit is equal to the 485 risk of having (k+1) v=1 bits in the 2k observations where b[0] 486 "should" be attributed to v=0. This risk depends on Q and k. 488 Setting k too large creates a risk of having estimator sequences that 489 are longer than the round-trip time (RTT) to be measured. If Q is 490 reasonably small, estimation will still eventually be possible after 491 a sufficient amount of measurements. One option is to keep Q 492 variable and determined by the client, introducing the possibility of 493 choice in RTT measurements. 495 Make the following assumptions: 497 1. the "real" round-trip time is 6+7=13, where 6 is the number of 498 ticks between the client and server, and 7 is the number of ticks 499 between server and client. 501 2. the server always reflects exactly the value of the bit it 502 receives, and 504 3. the client always inverts the value of the bit it receives, 505 meaning that all spin edges are always preserved. 507 Four RTTs of the spin bit according to specification would now give 508 rise to the following data, available to an on-path observer: 509 0000000000000111111111111100000000000001111111111111. To estimate 510 the time of a RTT, we could compute 13*4/4 = 13 time units. 512 Set Q=0.2. Now the four RTTs may instead be measured as 513 1001000000100111111001111100000010010110111011010111. With this 514 sequence, we would instead estimate (1+2+1+6+1+2+6+2+5+6+1+2+ 515 1+1+2+1+3+1+2+1+1+1+3)/23 = 2.26. That is clearly not satisfactory 516 if the target round-trip time estimation is 13. 518 Divide the RTT measurements into moving windows with k=2 (i.e., each 519 window contains (b[-2], b[-1], b[0], b[1], b[2])) to arrive at 520 [(10010), (00100), (01000), (10000), (00000), (00000), (00001), 521 (00010), (00100), etc]. Each window estimates b[0], so the "true" 522 value of bit 2 will be estimated by (10010), the true value of bit 523 three from (00100), and so forth. 525 Applying the procedure we are left with 526 000000000011111111111111000000000011111111111111, or 527 (10+14+14+10)/4=12. This is much better precision if the target 528 round-trip time estimation is 13. 530 3.2.2. Client and server perturbation 532 Now let us consider the case where both the client and server 533 randomize each transmitted bit, with probabilities Q and P 534 respectively. Using the same assumptions as in Section 3.2.1 and the 535 same target RTT of 13, and letting Q=0.2 and P=0.1, we may end up 536 measuring 0000000000000111111111011100000001010001111010011111 and 537 throw the method of moving windows for k=2 arriving at 538 000000000001111111111111000000000000011111001111 leaving us with 539 sequences of length (11, 13, 13, 5, 2, 4). 541 As previously mentioned, the risk of a bit being misidentified is 542 related to P, Q and k. Because a misidentified bit always make 543 sequences appear to be of shorter length, the sequences that measure 544 greater length should be taken as the RTT estimate. In this event 545 that we choose to only use that half of the esimated sequences with 546 the greatest length as a basis for the latency calculations, we would 547 have (11+13+13)/3=12.3 as the estimator for the RTT. 549 3.2.3. Discussion 551 In the introduction to this section, we observed that setting Q=0.5 552 would make any pattern recognition among the bits extremely difficult 553 for the most advanced of filters. We proceeded to discuss the case 554 Q=0.2 and a potential filter for this case in Section 3.2.1. If Q is 555 taken to be a parameter under client control, of course the client 556 could set Q so that latency measurements are made impossible. On the 557 other hand, such client control already exists, since the latency 558 spin bit is optional. (see Sec. 7.2 [RFC6973] and Section 17.3.1 559 [I-D-QUIC]). 561 In Section 3.2.2 we introduced the possiblity of yet another 562 parameter P, to be set by the server for determining server-side RRM 563 application. The moving windows filtering method applied to make 564 sense of on-path observations remains the same. 566 The filtering methods applied in this section consistently under- 567 estimate the true latency. More accurate latency measurements may be 568 achieved by having a larger number of sequences observed. 570 4. Simulation 572 TODO 574 5. Conclusion 576 The spin bit is associated with an IP address which creates 577 linkability (see [RFC6973] and [RFC8280]). The privacy concern 578 associated with a spin bit is, additionally, that latency 579 measurements will enable inferrence of the location or distance of 580 the device associated with that particular IP address. 582 In Section 3.1.1, it was seen Randomized response mechanisms (RRM) 583 would either cause the utility of the spin bit to disappear entirely 584 (by rendering any measurement futile) or cause the primary privacy- 585 reducing inferrence to remain a problem, as long as a sufficiently 586 large amount sequential measurements were done. Each measurement 587 would continue to be tied to fixed identifier, which necessarily 588 implies privacy loss. Interestingly, Section 3.1.1 also highlights 589 fundamental trade-offs between privacy-preserving mechanisms and 590 measurement utility: by setting Q=0, we were able to avoid ending up 591 in a sink, which would improve the possibility of measurement, but in 592 doing so removed all agency from the client to falsify its responses. 594 In Section 3.2.1 we saw that setting Q=0.5 could obfuscate the spin 595 edge from an on-path observer. Since the latency spin bit is an 596 optional feature, an easier method of accomplishing such obfuscation 597 would be to simply to turn the spin bit off. Setting Q < 0.5 would 598 instead let the client make it easier or more difficult for the on- 599 path observer to correctly estimate latency. In Section 3.2.1 and 600 Section 3.2.2 we particularly conclude that under-estimation of 601 latency is the most likely outcome of this RRM. 603 It is not clear that RRM would ultimately bring any particular 604 privacy benefit beyond what is already guaranteed in the present 605 specification of the spin bit in Section 17.3.1 [I-D-QUIC]. 607 6. Informative References 609 [AA-CL] Andersdotter, A. and C. Laengstroem, "Differential Privacy 610 (PEARG, IETF104)", March 2019, 611 . 615 [DWORK] Roth, A. and C. Dwork, "The Algorithmic Foundations of 616 Differential Privacy", 2014, 617 . 620 [FOX] Fox, J., "Randomized Response and Related Methods: 621 Surveying Sensitive Data", February 2017. 623 [I-D-QUIC] 624 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 625 and Secure Transport", September 2019, 626 . 629 [KUEHLEWIND] 630 Kuehlewind, M. and B. Trammel, "The QUIC Latency Spin Bit 631 (draft-ietf-quic-spin-exp-01)", October 2018, 632 . 634 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Petersen, J., 635 Morris, J., Hansen, M., and R. Smith, "Privacy 636 Considerations for Internet Protocols", RFC 6973, 637 DOI 10.17487/RFC6973, July 2013, 638 . 640 [RFC8280] Ten Oever, N. and C. Cath, "Human Rights Considerations 641 for Internet Protocols", RFC 8280, DOI 10.17487/RFC8280, 642 October 2017, . 644 [TENOEVER-MARTINI] 645 Martini, B. and N. Ten Oever, "QUIC Human Rights Review 646 (draft-martini-hrpc-quichr-00)", October 2018, 647 . 650 [TRAMMEL] Trammel, B., Boucadair, M., Even, R., Fioccola, G., 651 Fossati, T., Ihlar, M., Morton, A., and E. Stephan, 652 "Adding Explicit Passive Measurability of Two-Way Latency 653 to the QUIC Transport Protocol (draft-trammell-quic-spin- 654 03)", May 2018, . 657 Authors' Addresses 659 Amelia Andersdotter 660 ARTICLE 19 661 Free Word Centre, 60 Farringdon Road 662 London EC1R 3GA 663 United Kingdom 665 Email: amelia@article19.org 667 Shivan Sahib 668 Salesforce 670 Email: shivankaulsahib@gmail.com