Re: [Pearg] Adoption call for "Randomized Response Mechanisms in RRT Measurements for HTTP/3"

[Mirja Kuehlewind <[e-mail]>]

Hi again,

I just realized (as I had two windows open) that I'm citing below text from an old version of the predecessor draft (which had quic in the name). This text was removed/changed in the current draft, however, I think those point still remain valid. The current draft only says:

"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]."

My conclusion to this point is that there is no additional benefit and the obfuscation proposed in this document will in many cases render the signal completely unusable and will likely not reach the goal to preserve any utility as many transmissions are short and there is already a lot of noise in the network.  Therefore it is really preferred (and much easier) to disable spinbit support if privacy is seen at risk (e.g. in cases where VPNs are used as it was already discussed and agreed in the QUIC wg). 

Mirja


On 02.11.20, 13:35, "Pearg on behalf of Mirja Kuehlewind" <[e-mail] on behalf of mirja.kuehlewind=[e-mail]> wrote:

    Hi Chris, hi all,

    sorry for my late reply. I finally found some time to review this draft.

    First of all one quick question: why was the name changed from QUIC to HTTP/3 given the draft discusses a function of the QUIC...?

    Then I'm not really in support for the adoption of this draft for two main technical reasons:

    1) As stated in the draft, there are already proposed mechanisms QUIC specification to address the need to disable the spinbit:
    "it is unclear whether RRM
       has advantages larger than already existing privacy mechanisms
       included in the QUIC draft (such as making the spin bit optional, or
       requiring that 1/8 of all streams are not measurable)"

    2) Further the document says:
    " But the whole point of differential
       privacy mechanisms, including RRM, is using statistical methods to
       ensure that data can be made more privacy-preserving while also
       preserving the data utility.  In the case of the spin bit, it is the
       utility of the data that allegedly violates privacy, which means
       differential privacy is an intuitively bad tool to address privacy
       concerns."
    For this reason there is the option in QUIC to disable the spinbit entirely. Trying to add further fuzziness to the spinbit (when decided by the endpoint to enable) will in most cases simply make the signal unusable. This is because to measure the RTT you already need a certain amount of packets, also because there might network interfere that already make the signal noisy, and many transmission are short.

    Further the draft actually does not discuss the privacy risk of this information. There was an extensive analysis in the QUIC working group that concluded that "[t]he geolocation threat appears negligible and no other threats were identified" (see https://www.ietf.org/proceedings/100/slides/slides-100-quic-sessa-spin-bit-evaluation-design-team-report-00). I don't think this group should adopt an document that is based on assumption which has been neglected by the working group that is actually specifying the protocol.

    Mirja


    On 16.10.20, 15:22, "Pearg on behalf of Christopher Wood" <[e-mail] on behalf of [e-mail]> wrote:

        This message starts a two week adoption call for "Randomized Response Mechanisms in RRT Measurements for HTTP/3," located here:

           https://tools.ietf.org/html/draft-andersdotter-rrm-for-rrt-in-http3-00

        Please review the draft and indicate whether or not you would like to see this draft adopted by PEARG. 

        This call for adoption ends on October 30, 2020.

        Best,
        Chris, for the chairs

        -- 
        Pearg mailing list
        [e-mail]
        https://protect2.fireeye.com/v1/url?k=250a60b8-7baace75-250a2023-866132fe445e-bbbcd97773754954&q=1&e=53be6d3f-ae58-498c-beca-e2dba355cbfd&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fpearg

    -- 
    Pearg mailing list
    [e-mail]
    https://protect2.fireeye.com/v1/url?k=b161e66f-eefadc2a-b161a6f4-867b36d1634c-6b4135653ff1b0b3&q=1&e=2e7581ce-31bf-495b-a51a-9cc1f39e00c6&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fpearg