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

[Christian Huitema <[e-mail]>]

On 11/8/2020 3:54 PM, Amelia Andersdotter wrote:
> 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).

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


>
> best regards,
>
> Amelia
>
>
> On 2020-11-02 14:18, Mirja Kuehlewind wrote:
>> 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
>>