Re: Structuring the BKK spin bit discussion

"Brian Trammell (IETF)" <> Wed, 31 October 2018 08:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE59130DED for <>; Wed, 31 Oct 2018 01:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqgYDIDsnuch for <>; Wed, 31 Oct 2018 01:38:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A58A0129619 for <>; Wed, 31 Oct 2018 01:38:46 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with ESMTP id 9A036341C8E; Wed, 31 Oct 2018 09:38:44 +0100 (CET)
X-Iway-Path: 0
Received: from localhost (localhost []) by localhost (ACF/20439.20981); Wed, 31 Oct 2018 09:38:44 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 31 Oct 2018 09:38:44 +0100 (CET)
Received: from [] (account HELO []) by (CommuniGate Pro SMTP 6.2.9) with ESMTPSA id 72209542; Wed, 31 Oct 2018 09:38:44 +0100
From: "Brian Trammell (IETF)" <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_32313F8E-FD9F-450A-9DEB-7301C4936572"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Structuring the BKK spin bit discussion
Date: Wed, 31 Oct 2018 09:38:43 +0100
In-Reply-To: <>
Cc: Christian Huitema <>, Mikkel Fahnøe Jørgensen <>, Marcus Ihlar <>, QUIC WG <>
To: Martin Thomson <>
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <> <> <> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Oct 2018 08:38:49 -0000

hi Martin,

> On 30 Oct 2018, at 23:55, Martin Thomson <> wrote:
> On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <> 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 -- 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.