Re: Structuring the BKK spin bit discussion

["Brian Trammell (IETF)" <[e-mail]>]

hi Martin,

> On 30 Oct 2018, at 23:55, Martin Thomson <[e-mail]> wrote:
> 
> On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <[e-mail]> wrote:
>> 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.
> 
> Or are we looking for random per-path?
> 
> That notion would seem to tilt the balance more in favour of the
> "discretionary" option over the "negotiated" one on the basis that
> spinning/not doesn't become a linkability consideration.

Yeah, I noticed this when writing up https://github.com/quicwg/base-drafts/pull/1937 -- if a handshake negotiating a spin version commits both endpoints to spin on that connection for every subsequent CID, then if endpoints implementing spin are relatively rare (which may be the case no matter what early in the deployment curve), this sticky state is a potential linkability issue. If endpoints willing to negotiate spin are widely deployed, linkability becomes negligible.

One can fix this by allowing endpoints that have negotiated spinning to transition to discretionary non-spinning on a CID change, since for this to be a useful exercise of the version negotiation machinery, the MUST spin is only important for the CID directly after the handshake.

But you're right, the additional complexity starts making negotiation look less attractive.

Cheers,

Brian