[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Research Task Force                             A. Andersdotter
Internet-Draft                                                ARTICLE 19
Intended status: Informational                                  S. Sahib
Expires: May 6, 2020                                          Salesforce
                                                        November 3, 2019


     Randomized Response Mechanisms in RRT Measurements for HTTP/3
               draft-andersdotter-rrm-for-rrt-in-http3-00

Abstract

   The latency spin bit is an optional feature included in the QUIC
   transport protocol [I-D-QUIC].  It enables passive, on-path
   observations for estimation of latency.  This document presents the
   results of an inquiry into the potential of using randomized response
   mechanisms (RRM) to reduce privacy loss in latency measurements.  It
   concludes that RRM could be used to introduce choice for clients in
   preserving privacy in latency measurements.  But the trade-offs,
   especially since the latency spin bit is already optional, do not
   favour RRM.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 6, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Andersdotter & Sahib       Expires May 6, 2020                  [Page 1]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Randomized Response Mechanisms  . . . . . . . . . . . . . . .   2
   3.  Application to latency spin bit . . . . . . . . . . . . . . .   3
     3.1.  RRM at edge transition  . . . . . . . . . . . . . . . . .   6
       3.1.1.  No reset and no edge identifying bit  . . . . . . . .   7
       3.1.2.  Reset and no edge identifying bit . . . . . . . . . .   8
       3.1.3.  An edge identifying bit . . . . . . . . . . . . . . .   9
       3.1.4.  Discussion  . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  RRM at each bit . . . . . . . . . . . . . . . . . . . . .  10
       3.2.1.  Client perturbation . . . . . . . . . . . . . . . . .  11
       3.2.2.  Client and server perturbation  . . . . . . . . . . .  12
       3.2.3.  Discussion  . . . . . . . . . . . . . . . . . . . . .  12
   4.  Simulation  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   At the IETF104 convening of the Privacy Enhancements and Assessments
   Research Group (PEARG), a presentation on Differential Privacy
   ([AA-CL]) gave rise to the idea of trying to apply Randomized
   Response methods to the QUIC Spin Bit described in [TRAMMEL] and
   [KUEHLEWIND].  Now incorporated in Section 17.3.1 [I-D-QUIC], the
   latency spin bit has generated controversy from a privacy
   perspective, both in the Working Group meetings and on e-mailing
   lists.  Controversies were re-ignited through the publication of a
   Human Rights Consideration in [TENOEVER-MARTINI].  Applying RRM is an
   attempt to address two problems: the privacy loss incurred through
   the spin bit, and considering the potential of using RRM to have more
   than one bit assisting in latency measurement as per previous
   proposals.

2.  Randomized Response Mechanisms

   Randomized Response Mechanisms (RRM) rely on the ability to make
   sense of data with known errors and were originally developed to
   facilitate surveys on sensitive topics such as alcohol or drug abuse
   or political affiliation.  The design allows a survey taker to
   provide, with some known probability P, a "false" answer ("yes"



Andersdotter & Sahib       Expires May 6, 2020                  [Page 2]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   instead of "no", for example) to a survey question.  It is meant to
   encourage truthful answers even in surveys where participants may
   otherwise feel compelled to give false answers.

   Randomized response trials were originally created for binary
   environments: if a series of measurements have only two possible
   outcomes (0 or 1, yes or no, true or false, for instance), it is the
   idea that allowing individual respondents to answer "falsely" at a
   predictable rate will still preserve the ability to make inferences
   on the entire set of respondents.  The latency spin bit, being a bit,
   is binary outcome variable.  Each time it is measured, the idea is
   that it can either "truthfully" report its value as what it should be
   according to [TRAMMEL], or it could, at some known rate or
   probability, report the opposite value.

   RRMs are easily illustrated for binary response problems.  Let's take
   as an example "Did you go to the last IETF meeting?"  The answer to
   this question is either yes or no.  Let us suppose that 25% of all
   responses are known to be false, and that 80% of all respondents
   answered yes.  Then 60% of the respondents who answered yes can be
   assumed to have done so truthfully, while 5% of the respondents who
   answered no have done so falsely. 65% of the respondents can
   therefore be estimated to have actually attended the last IETF
   meeting.

   RRMs can also be applied to multiple choice questions.  Estimation of
   true proportions becomes more difficult as the number of possible
   answers per question goes up.  Further examples, including formulas
   and calculations, can be found in [DWORK] and [FOX].

3.  Application to latency spin bit

   As described in [TRAMMEL], the latency spin bit is a mechanism for
   measuring round-trip-times (RTT) in the QUIC protocol.  The
   investigation in this document relies on [TRAMMEL] for its
   understanding of the basic operation of the latency spin bit, and in
   particular the following paragraphs and figures from the document are
   quoted to facilitate the description of RRM below:

   [Begin quote] Initially, during connection establishment, no packets
   with a spin bit are in flight, as shown in Figure 1.










Andersdotter & Sahib       Expires May 6, 2020                  [Page 3]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   +--------+   -  -  -  -  -   +--------+
   |        |     -------->     |        |
   | Client |                   | Server |
   |        |     <--------     |        |
   +--------+   -  -  -  -  -   +--------+

      Figure 1: Initial state, no spin bit between client and server

   Either the server, the client, or both can begin sending packets with
   short headers after connection establishment, as shown in Figure 2;
   here, no spin edges are yet in transit.

   +--------+   0  0  -  -  -   +--------+
   |        |     -------->     |        |
   | Client |                   | Server |
   |        |     <--------     |        |
   +--------+   -  -  0  0  0   +--------+

       Figure 2: Client and server begin sending packets with spin 0

   Once the server's first 0-marked packet arrives at the client, the
   client sets its spin value to 1, and begins sending packets with the
   spin bit set, as shown in Figure 3.  The spin edge is now in transit
   toward the server.

   +--------+   1  0  0  0  0   +--------+
   |        |     -------->     |        |
   | Client |                   | Server |
   |        |     <--------     |        |
   +--------+   0  0  0  0  0   +--------+

                     Figure 3: The bit begins spinning

   Five ticks later, this packet arrives at the server, which takes its
   spin value from it and reflects that value back on the next packet it
   sends, as shown in Figure 4.  The spin edge is now in transit toward
   the client.

   +--------+   1  1  1  1  1   +--------+
   |        |     -------->     |        |
   | Client |                   | Server |
   |        |     <--------     |        |
   +--------+   0  0  0  0  1   +--------+

                  Figure 4: Server reflects the spin edge






Andersdotter & Sahib       Expires May 6, 2020                  [Page 4]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   Five ticks later, the 1-marked packet arrives at the client, which
   inverts its spin value and sends the inverted value on the next
   packet it sends, as shown in Figure 5.

         obs. points  X  Y
   +--------+   0  1  1  1  1   +--------+
   |        |     -------->     |        |
   | Client |                   | Server |
   |        |     <--------     |        |
   +--------+   1  1  1  1  1   +--------+
                         Y

                  Figure 5: Client inverts the spin edge

   [End quote]

   In each iteration going from Figure 4 to Figure 5 a sequence of 0s or
   1s the length of which is k0 for iteration 0, k1 for iteration 1, and
   so forth, can be observed (by on-path observers X or Y in Figure 5).
   The length of each sequence equals the amount of ticks required to
   pass from the client back to the client.  After observation n lengths
   of such sequences, (k[0], ..., k[n]), an average can be taken over
   k[j].  This average can be multiplied by the amount of time per tick
   (a quantity which is assumed to be known) to get a value for the
   round-trip time (RTT).

   Applying randomized response mechanisms (RRMs) perturbs the observed
   sequence lengths (k[0], ..., k[n]).  The perturbation will have the
   effect of lengthening, shortening, or making more arbitrary the
   lengths of the sequences, thereby increasing the variance, or disable
   the possibility, of an estimator of the true RTT value.

   The server or the client is assumed to behave as described in
   Figure 4 and Figure 5, unless specifically stated otherwise.  That
   means the assumed default behaviour is that a "truly" reflecting
   server that receives a bit set to v=0 always reflects a bit with v=0.
   In an RRM application, a server which "falsely" reflects a bit
   receives a bit set to v=0 and reflects a bit set to v=1.  Similarly,
   the assumed default behaviour of a client is that it "truly" inverts
   a bit, so that receiving a bit set to v=0 causes it to transmit a bit
   set to v=1.  In an RRM application, the client may "falsely" transmit
   a bit set to v=0 even when it has received a bit set to v=0.  The
   receiving of a spin edge is assumed to be a trigger event for a
   reflection or an inversion.  The server and the client are assumed to
   have an internal spin value that determines the spin bit that goes
   out.  Every time a spin edge comes in (a trigger), this internal spin
   value is changed, changing also the outgoing spin value.




Andersdotter & Sahib       Expires May 6, 2020                  [Page 5]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   An additional assumption is that the server and client behave
   independently of one another.  This means that the server has no
   information on whether the client has omitted an inversion, and the
   client has no information on whether the server has omitted a
   reflection.  Omissions are therefore independent events.

   We have looked at two ways of perturbing measurements:

      1.  RRMs are applied so that edge transitions do not occur with
      probability P or Q for server and client respectively.

      2.  RRMs are applied so that that each bit transmitted, whether or
      not an inversion is occurring, has a probability P of being the
      "wrong" value.

   They will be dealt with in turn, identifying pitfalls and potential
   ways of addressing those pitfalls.  The goal is to have better
   privacy-protecting properties while continuing to allow utility of
   the on-path observations in latency measurements.

3.1.  RRM at edge transition

   The omission of a reflection or inversion creates difficulties.
   Namely, let's say the client omits the inversion in Figure 5.  Now
   there is no longer a spin edge so there is nothing to activate future
   reflections/inversions.

   A possible work-around is to do random re-sets of the spin bit, i.e.,
   starting the process fresh from Figure 2.  Observers X and Y in
   Figure 5 would then get a series of measurements (k0, ..., kn), some
   of which were far too large, but would, over time, be able to deduce
   RTT from the smaller measurements.  The expected proportion of large
   and small measurements in the whole set of measurements could be
   determined from the probabilities that a edge transition does not
   happen and the probability that the spin bit is re-initiated.

   Another possible work-around is having an additional bit to indicate
   a spin edge, assigned by the server to the bit which is (not)
   reflected in Figure 4, or by the client to the bit which is (not)
   inverted in Figure 5.  In this case there would not be a point in
   applying RRM since the placement of the spin edge would no longer be
   obfuscated.

   If the ordinary spin edge is obfuscated by through omission of edge
   transition, and the edge-identifying bit is also, with some
   probability, not correctly identifying an edge, the utility of having
   two latency bits again goes up at no additional loss of privacy.




Andersdotter & Sahib       Expires May 6, 2020                  [Page 6]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


3.1.1.  No reset and no edge identifying bit

   The bit starts spinning with value v=1 in Figure 3.  At the point of
   reflection (see Figure 4), it does not reflect with probability P.
   At the point of inversion (see Figure 5), it does not invert with
   probability Q.  We consider P and Q respectively to be the
   probability that the server or client does not behave in the way
   specified.

   Let -> be the operation that a bit changes value.  A correct
   reflection will be denoted R: a->a.  A correct inversion is denoted
   I:a->b.  Prefixing R or I with a ! denotes that edge transition was
   not done correctly.  The variables a and b assume the values 0 or 1
   and are never equal.  P(R: a->a) = 1-P and P(I: a->b) = 1-Q, while
   P(!R: a->b) = P and P(!I: a->a) = Q.  An expression like R(v: 1->1)
   -> !I(v: 1->1) means that a bit whose initial value is 1 is correctly
   reflected, and then incorrectly inverted.  We can abbreviate this to
   [1->1->1].  R must follow I and vice versa, so we will have a chain
   of events R->I->R->I-> etc.

   In order for a reflection or an inversion to occur, there must be a
   trigger.  The spin edge is the trigger.  But in the event of
   [1->1->1] the spin edge has disappeared!  Once the bit spins back to
   the reflection, it will have the same value as when it started.  In
   fact, regardless of the starting value, any R->I event that results
   in [1->1] or [0->0] leads to a loop.

   We can define the following events:

      A: [1->1].

      B: [0->0].

      C: [0->1].

      D: [1->0].

   Event A can occur as a result of (!R, !I) for starting point v=0, or
   as a result of (R, !I) for starting point v=1 or v=0.  Event B can
   occur as a result of (!R, !I) for starting point v=1, or as a result
   of (R, !I) for starting point v=1 or v=0.  Event C occurs as a result
   of (!R, I) for starting point v=1, or (R, I) for starting point v=0.
   Event D occurs as a result of (!R, I) for starting point v=0 or (R,
   I) for starting point v=0.  The starting point v can be taken as the
   final digit in each event, meaning that for the event following C,
   the starting point would be v=1, and for the event following D, the
   starting point would be v=0.




Andersdotter & Sahib       Expires May 6, 2020                  [Page 7]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   With this information, and the probabilities determined above, we can
   create a transition matrix in the Markovian sense.


   +----+-----------+-----------+-----------+-----------+
   |    |     A     |     B     |     C     |     D     |
   +----+-----------+-----------+-----------+-----------+
   | A  |     1     |     0     |     0     |     0     |
   +----+-----------+-----------+-----------+-----------+
   | B  |     0     |     1     |     0     |     0     |
   +----+-----------+-----------+-----------+-----------+
   | C  |  (1-P)Q   |     Q     |   P(1-Q)  | (1-P)(1-Q)|
   +----+-----------+-----------+-----------+-----------+
   | D  |     Q     |  (1-P)Q   |(1-P)(1-Q) |  P(1-Q)   |
   +----+-----------+-----------+-----------+-----------+

       Figure 6: RRM transition matrix, no reset and no edge-id bit

   It should be quite clear from this matrix that events A and B act as
   sinks.  Because ending in a sink removes all possibility of future
   measurements, we could hope to avoid this situation.  The easiest way
   is setting Q=0, which would imply there is always a correct
   inversion.  For any Q > 0, this process will eventually end up in a
   sink.

3.1.2.  Reset and no edge identifying bit

   The possible outcomes are as in Section 3.1.1, and the problem to be
   resolved is that the spin edge eventually disappears with probability
   1.

   Introducing the probability R of a random re-set of the spin bit at
   every m:th bit transmission can "re-initiate" the edge by taking the
   entire system back into the situation described in Figure 4 (with the
   modification that it is not assumed that the starting point must be
   v=1; the starting point could also be reset to v=0).  It is assumed
   that a re-set occurs on the client-side, and not on the server-side.

   The true number of ticks in a round-trip time is C.  If R>0 and m >>
   C, the process will be reset every period of km ticks, where k is an
   integer whose distribution is geometric with parameter R.  After km
   ticks, an on-path observer may pick up a sequence that can be used as
   a basis for measuring the round-trip time.

   In Figure 7 the situation where m=2 is illustrated.






Andersdotter & Sahib       Expires May 6, 2020                  [Page 8]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   +---+----------+--------+----------+--------+----------+----------+
   |   |   A,m0   |  A,m1  |   B,m0   |   B,m1 |    C     |     D    |
   +---+----------+--------+----------+--------+----------+----------+
   |A,0|     0    |   1    |    0     |    0   |    0     |     0    |
   +---+----------+--------+----------+--------+----------+----------+
   |A,1|    1-R   |   0    |    0     |    0   |    R     |     0    |
   +---+----------+--------+----------+--------+----------+----------+
   |B,0|     0    |   0    |    0     |    1   |    0     |     0    |
   +---+----------+--------+----------+--------+----------+----------+
   |B,1|     0    |   0    |   1-R    |    0   |    R     |     0    |
   +---+----------+--------+----------+--------+----------+----------+
   | C |  (1-P)Q  |   0    |    Q     |    0   |  P(1-Q)  |(1-P)(1-Q)|
   +---+----------+--------+----------+--------+----------+----------+
   | D |     Q    |   0    |  (1-P)Q  |    0   |(1-P)(1-Q)|  P(1-Q)  |
   +---+----------+--------+----------+--------+----------+----------+

              Figure 7: RRM TM, Reset at m=2, no edge-id bit

   If m (or km | k ~ Ge(R)) is too small, there will never be any sound
   measurements since the process will always start over before a
   measurement appears.  Using a reset function is therefore especially
   burdensome for an on-path observer in cases where latencies are a
   priori expected to be large.

3.1.3.  An edge identifying bit

   The possible outcomes are as in Section 3.1.1, and the problem to be
   resolved is that the spin edge eventually disappears with probability
   1.

   Introducing an edge identifying bit, which may or may not hold a true
   value with probability S, could help mitigate this problem.  This
   could effectively be seen as a recursive RRM: because the original
   RRM risks removing the utility of the spin bit entirely, another bit
   to which RRM is applied is added.

   Logically, adding another identifying bit increases the possible set
   of states of the Markovian chains described in Section 3.1.1 and
   Section 3.1.2.  In fact, the systems would still possess similar
   short-comings, but with different probabilities.  The exception is if
   the identifying bit is always on with probability S=1.  In this case,
   the privacy-enhancing properties sought in Section 3.1.1 and
   Section 3.1.2 would be lost, since the main goal of RRM in both of
   those cases is to perturb the measurements (k0, ...., kn) used to
   estimate round-trip times.






Andersdotter & Sahib       Expires May 6, 2020                  [Page 9]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


3.1.4.  Discussion

   In Section 3.1.1 we saw that applying RRM at reflection and inversion
   could create a situation where the spin edge disappears.  There are
   two parameters, P and Q, which are set by the client and server
   respectively.

   We could reduce the risk of the spin edge disappearing by setting the
   probability of a wrongful inversion to Q=0.  However, inversion is an
   activity undertaken by the client and Q is a parameter under the
   clients control.  Since the client is the entity assumed, in most
   cases, to be the most likely actor to be a human, natural person (in
   either case, more likely than the server), this solution would remove
   power from the client.  Forcibly setting Q=0 would violate the
   assumptions of user control in Section 7.2 [RFC6973].

   In Section 3.1.2 we considered whether it was possible to reset a
   latency spin bit whose edge has disappeared.  Effectively, resetting
   would improve an on-path observers chances of making measurements,
   but it also introduces a delay for the acquisition of useful
   measurements.

   We assume that the client will set Q>0 and that this is under the
   client's control, and have three additional parameters: P, m and R.
   Both m and R can be under the client's control.  We found that km |
   k~Ge(R) has an impact on the ability to measure latency when latency
   is large.  In practice, an average human, natural person is probably
   not going to choose parameters Q, m and R (even though they could be
   made available at settings in an interface).  Setting of these
   parameters will instead likely be under the control of the entity
   that produces latency spin bit capable software.

   In Section 3.1.3 we conclude that adding an edge-identifying bit is
   not a remedy to any of the issues with the methods in Section 3.1.1
   or Section 3.1.2.  It introduces the possibility of yet another
   client-controlled parameter S, but the obfuscating effects derived
   from S could instead be obtained by regulating previously suggested
   parameters Q, m or R.

3.2.  RRM at each bit

   Let us say any bit transmitted from either the client or the server
   is "off" in relation to what it proposed in the Spin Bit model with
   some probability Q.  If Q = 0.5, the spinning bits will come across
   as a random 0s and 1s and it will be difficult to estimate any edge.
   However, if Q is less than 0.5, the spin edge can be estimated for
   instance by computing an average number of 0s or 1s in the past m
   ticks.  For all averages above some cut-off rate, a measurement



Andersdotter & Sahib       Expires May 6, 2020                 [Page 10]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   counter could be incremented by one.  Eventually one would end up
   with a series (k'0, ..., k'n) that roughly corresponds to (k0, ...,
   kn) above.

3.2.1.  Client perturbation

   The bit spins in the foreseen way.  Every time a bit is transmitted,
   there is a probability Q that it holds a different value than it
   should.  In Figure 5 , either measurements station X or both stations
   Y observe a passing bit, as well as bits passing before or after that
   bit (if any).  After observing 2k+1 bits (b[-k], ..., b[0], ...,
   b[k]) the true value of bit b[0] is estimated, for instance based on
   whether the majority of b[i] were v=0 or v=1.  The estimated value is
   then used to increment a sequence counter.

   The estimator follows a binomial distribution (drawing with
   replacement), and the risk of misidentifying a bit is equal to the
   risk of having (k+1) v=1 bits in the 2k observations where b[0]
   "should" be attributed to v=0.  This risk depends on Q and k.

   Setting k too large creates a risk of having estimator sequences that
   are longer than the round-trip time (RTT) to be measured.  If Q is
   reasonably small, estimation will still eventually be possible after
   a sufficient amount of measurements.  One option is to keep Q
   variable and determined by the client, introducing the possibility of
   choice in RTT measurements.

   Make the following assumptions:

      1. the "real" round-trip time is 6+7=13, where 6 is the number of
      ticks between the client and server, and 7 is the number of ticks
      between server and client.

      2. the server always reflects exactly the value of the bit it
      receives, and

      3. the client always inverts the value of the bit it receives,
      meaning that all spin edges are always preserved.

   Four RTTs of the spin bit according to specification would now give
   rise to the following data, available to an on-path observer:
   0000000000000111111111111100000000000001111111111111.  To estimate
   the time of a RTT, we could compute 13*4/4 = 13 time units.

   Set Q=0.2.  Now the four RTTs may instead be measured as
   1001000000100111111001111100000010010110111011010111.  With this
   sequence, we would instead estimate (1+2+1+6+1+2+6+2+5+6+1+2+




Andersdotter & Sahib       Expires May 6, 2020                 [Page 11]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   1+1+2+1+3+1+2+1+1+1+3)/23 = 2.26.  That is clearly not satisfactory
   if the target round-trip time estimation is 13.

   Divide the RTT measurements into moving windows with k=2 (i.e., each
   window contains (b[-2], b[-1], b[0], b[1], b[2])) to arrive at
   [(10010), (00100), (01000), (10000), (00000), (00000), (00001),
   (00010), (00100), etc].  Each window estimates b[0], so the "true"
   value of bit 2 will be estimated by (10010), the true value of bit
   three from (00100), and so forth.

   Applying the procedure we are left with
   000000000011111111111111000000000011111111111111, or
   (10+14+14+10)/4=12.  This is much better precision if the target
   round-trip time estimation is 13.

3.2.2.  Client and server perturbation

   Now let us consider the case where both the client and server
   randomize each transmitted bit, with probabilities Q and P
   respectively.  Using the same assumptions as in Section 3.2.1 and the
   same target RTT of 13, and letting Q=0.2 and P=0.1, we may end up
   measuring 0000000000000111111111011100000001010001111010011111 and
   throw the method of moving windows for k=2 arriving at
   000000000001111111111111000000000000011111001111 leaving us with
   sequences of length (11, 13, 13, 5, 2, 4).

   As previously mentioned, the risk of a bit being misidentified is
   related to P, Q and k.  Because a misidentified bit always make
   sequences appear to be of shorter length, the sequences that measure
   greater length should be taken as the RTT estimate.  In this event
   that we choose to only use that half of the esimated sequences with
   the greatest length as a basis for the latency calculations, we would
   have (11+13+13)/3=12.3 as the estimator for the RTT.

3.2.3.  Discussion

   In the introduction to this section, we observed that setting Q=0.5
   would make any pattern recognition among the bits extremely difficult
   for the most advanced of filters.  We proceeded to discuss the case
   Q=0.2 and a potential filter for this case in Section 3.2.1.  If Q is
   taken to be a parameter under client control, of course the client
   could set Q so that latency measurements are made impossible.  On the
   other hand, such client control already exists, since the latency
   spin bit is optional. (see Sec. 7.2 [RFC6973] and Section 17.3.1
   [I-D-QUIC]).

   In Section 3.2.2 we introduced the possiblity of yet another
   parameter P, to be set by the server for determining server-side RRM



Andersdotter & Sahib       Expires May 6, 2020                 [Page 12]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   application.  The moving windows filtering method applied to make
   sense of on-path observations remains the same.

   The filtering methods applied in this section consistently under-
   estimate the true latency.  More accurate latency measurements may be
   achieved by having a larger number of sequences observed.

4.  Simulation

   TODO

5.  Conclusion

   The spin bit is associated with an IP address which creates
   linkability (see [RFC6973] and [RFC8280]).  The privacy concern
   associated with a spin bit is, additionally, that latency
   measurements will enable inferrence of the location or distance of
   the device associated with that particular IP address.

   In Section 3.1.1, it was seen Randomized response mechanisms (RRM)
   would either cause the utility of the spin bit to disappear entirely
   (by rendering any measurement futile) or cause the primary privacy-
   reducing inferrence to remain a problem, as long as a sufficiently
   large amount sequential measurements were done.  Each measurement
   would continue to be tied to fixed identifier, which necessarily
   implies privacy loss.  Interestingly, Section 3.1.1 also highlights
   fundamental trade-offs between privacy-preserving mechanisms and
   measurement utility: by setting Q=0, we were able to avoid ending up
   in a sink, which would improve the possibility of measurement, but in
   doing so removed all agency from the client to falsify its responses.

   In Section 3.2.1 we saw that setting Q=0.5 could obfuscate the spin
   edge from an on-path observer.  Since the latency spin bit is an
   optional feature, an easier method of accomplishing such obfuscation
   would be to simply to turn the spin bit off.  Setting Q < 0.5 would
   instead let the client make it easier or more difficult for the on-
   path observer to correctly estimate latency.  In Section 3.2.1 and
   Section 3.2.2 we particularly conclude that under-estimation of
   latency is the most likely outcome of this RRM.

   It is not clear that RRM would ultimately bring any particular
   privacy benefit beyond what is already guaranteed in the present
   specification of the spin bit in Section 17.3.1 [I-D-QUIC].








Andersdotter & Sahib       Expires May 6, 2020                 [Page 13]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


6.  Informative References

   [AA-CL]    Andersdotter, A. and C. Laengstroem, "Differential Privacy
              (PEARG, IETF104)", March 2019,
              <https://datatracker.ietf.org/meeting/104/materials/
              slides-104-pearg-amelia-christoffer-differential-privacy-
              00>.

   [DWORK]    Roth, A. and C. Dwork, "The Algorithmic Foundations of
              Differential Privacy", 2014,
              <https://www.cis.upenn.edu/~aaroth/Papers/
              privacybook.pdf>.

   [FOX]      Fox, J., "Randomized Response and Related Methods:
              Surveying Sensitive Data", February 2017.

   [I-D-QUIC]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", September 2019,
              <https://tools.ietf.org/html/draft-ietf-quic-transport-
              23>.

   [KUEHLEWIND]
              Kuehlewind, M. and B. Trammel, "The QUIC Latency Spin Bit
              (draft-ietf-quic-spin-exp-01)", October 2018,
              <https://tools.ietf.org/html/draft-ietf-quic-spin-exp-01>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Petersen, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC8280]  Ten Oever, N. and C. Cath, "Human Rights Considerations
              for Internet Protocols", RFC 8280, DOI 10.17487/RFC8280,
              October 2017, <https://www.rfc-editor.org/info/rfc8280>.

   [TENOEVER-MARTINI]
              Martini, B. and N. Ten Oever, "QUIC Human Rights Review
              (draft-martini-hrpc-quichr-00)", October 2018,
              <https://tools.ietf.org/html/draft-martini-hrpc-quichr-
              00>.









Andersdotter & Sahib       Expires May 6, 2020                 [Page 14]


Internet-Draft            rrm-for-rrt-in-http3             November 2019


   [TRAMMEL]  Trammel, B., Boucadair, M., Even, R., Fioccola, G.,
              Fossati, T., Ihlar, M., Morton, A., and E. Stephan,
              "Adding Explicit Passive Measurability of Two-Way Latency
              to the QUIC Transport Protocol (draft-trammell-quic-spin-
              03)", May 2018, <https://www.ietf.org/archive/id/draft-
              trammell-quic-spin-03.txt>.

Authors' Addresses

   Amelia Andersdotter
   ARTICLE 19
   Free Word Centre, 60 Farringdon Road
   London EC1R 3GA
   United Kingdom

   Email: amelia@article19.org


   Shivan Sahib
   Salesforce

   Email: shivankaulsahib@gmail.com





























Andersdotter & Sahib       Expires May 6, 2020                 [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/