Re: Structuring the BKK spin bit discussion

[Christian Huitema <[e-mail]>]

On 10/30/2018 4:55 AM, Marcus Ihlar wrote:
>
> Making it more difficult to differentiate explicit opt-out from random
> opt-out is likely useful even if it doesn’t help in the particular
> Netflix case.
>
> Furthermore, just like Brian points out it is necessary to grease the
> bit if we want to change the bit semantics later on.
>
> I think the proposal has low enough complexity and potential benefits
> to be worthwhile.
>
>  
>
> *From:*QUIC <[e-mail]> *On Behalf Of *Mikkel Fahnøe Jørgensen
> *Sent:* den 30 oktober 2018 08:01
> *To:* Christian Huitema <[e-mail]>; [e-mail]
> *Subject:* Re: Structuring the BKK spin bit discussion
>
>  
>
> In the Netflix case it just takes 16 connections by the same user, or
> less when multiple users originate from the sane IP range.. Is it
> really practical (and thus worthwhile) to hide probabilistically as in
> Huitemas PR?
>

Mikkel is correct, we may not want a purely random per connection
behavior, but rather something "random per destination". This would
better mimic the opt-out behavior of a privacy-sensitive endpoint, which
would always opt out when contacting a specific destination. If I had to
implement it, I would not use a PRNG, but rather something compute the
hash of a local secret and either the peer address or the peer name.
That way, the client would opt out for all 16 Netflix connections, or
for none of them.

-- Christian Huitema