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

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Nov 2020 12:35:26 +0000

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" <[email-masked] on behalf of [email-masked]> 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
    [email-masked]
    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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Nov 2020 13:18:16 +0000

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" <[email-masked] on behalf of mirja.kuehlewind=[email-masked]> wrote:

    Hi Chris, hi all,

    Mirja

        Best,
        Chris, for the chairs

    -- 
    Pearg mailing list
    [email-masked]
    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

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 9 Nov 2020 00:54:52 +0100

Hi Mirja,

Correct - the over-all conclusion is that RRM is not ultimately very
useful. Throughout last year and this spring we were also on the hunt
for other potential areas of application, but we run into similar a
situation: a feature which can be made more private by RRM obfuscation
can be made even more private by simply being disabled.

We put it still in a draft since not all research leads down beneficial
paths (combating positive outcome bias!). A third potential area for RRM
is for padding bits (randomizing padding bits rather than padding with
only 0s).

best regards,

Amelia

-- 
^\...~...~...~...~...~.../^
Amelia Andersdotter
IETF SHMOO WG Co-Chair
https://datatracker.ietf.org/group/shmoo/about/

Director of Strategic Initiatives, CENTR
www.centr.org
^\...~...~...~...~...~.../^

---

From: Christian Huitema <[email-masked]>
Date: Sun, 8 Nov 2020 17:19:59 -0800

> is for padding bits (randomizing padding bits rather than padding with

In what context are you considering such padding bits? In the case of
QUIC, the Padding frames are encrypted as part of the payload. They
start as zero, but are random once encrypted.

There is a narrow and arcane issue with applying padding to coalesced
QUIC packets during the handshake phase. The payload of the UDP packets
carrying the Initial packets during the handshake must be padded to 1200
bytes. Some applications do that before encryption, and some do it after
encryption. When doing that after encryption, yes, non-random padding
will leak some info about the length of the Initial packets. But then,
the Initial packets are "encrypted" with a static well known key, so it
is not clear that requiring random padding will be very advantageous.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Nov 2020 01:48:10 +0000

Hiya,

On 09/11/2020 01:19, Christian Huitema wrote:
> There is a narrow and arcane issue with applying padding...

I figure there could be a useful RFC written describing
the circumstances when to pad with zero and when not. A
bit boring, yes, but would save some time for protocol
developers later on, as this question comes up over and
over.

I'm not sure if generalising beyond that might be useful
but wouldn't rule it out, e.g. to scope a draft at "how
and when to pad with what" or similar,

Cheers,
S.

PS: Before anyone asks: sorry, not volunteering myself
right now, just due to workload ;-)