Re: Structuring the BKK spin bit discussion

Roland Zink <> Thu, 01 November 2018 10:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACCCB124C04 for <>; Thu, 1 Nov 2018 03:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bKc2YRfz_pTN for <>; Thu, 1 Nov 2018 03:39:44 -0700 (PDT)
Received: from ( [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EF25127B92 for <>; Thu, 1 Nov 2018 03:39:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1541068782; s=strato-dkim-0002;; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=jcXDPyTJV/ha2Pe6G9MCQ78IF69JD8s8vP/IOU1vKgo=; b=SSGq/s29n6Ddn/Es8+ybPriEjuxQwQLsSqMhtPotqqYZw0NUOChwL19Zb2FiqbY0RK AmESZKFp071jyVZ3XwuvQ+ewMdoGtsrYOgdJTSpc0WyXKtKs7Zn5d3q4o5a8XGCUiGSB 2IQ7S4erANdQGxT+DWuq1m1eASY+EdEsRNejQs7xElyGCWOOqys9+GKsgvJlnKtsuph1 xrzlJxnnf+c4V6vCWgEBe4ku/BCNJsfxYqNR5hPqSBvGKz2Ae+rZRSj+W+7i3/CaSXyV nHT1GtSVX5NgrPrjgRCfmpKuYdNpeNEw1cxILy4ejXYlOozkxuC4JV9S57Nvvd4GN116 uqmQ==
X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQJHaSxcis="
Received: from [] by (RZmta 44.3 DYNA|AUTH) with ESMTPSA id R07dc3uA1Adg68P (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <>; Thu, 1 Nov 2018 11:39:42 +0100 (CET)
Subject: Re: Structuring the BKK spin bit discussion
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <> <> <> <> <> <>
From: Roland Zink <>
Message-ID: <>
Date: Thu, 01 Nov 2018 11:39:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Thu, 01 Nov 2018 10:39:47 -0000

Am 31.10.2018 um 19:04 schrieb Christian Huitema:
> On 10/31/2018 10:16 AM, Brian Trammell (IETF) wrote:
>> In the case that...
>> - end-to-end connection actually terminates at a location different than the apparent location in the endpoint IP address, because the endpoint IP address is a VPN tunnel endpoint
>> - ...the "hidden" endpoint is very far (> ~3000-5000km) from the apparent location
>> - ...that VPN tunnel exists solely to make the end-to-end association appear to originate from at or near the VPN tunnel endpoint (e.g., anti-geofencing)
> The actual scenario relates to UDP/QUIC proxies, and how they would
> compare to TCP/TLS proxies.
> Today, I can build a TCP/TLS proxy that accepts connections at port 443,
> examines the (possibly encrypted) SNI in the client Hello, establishes a
> TCP connection to the hidden destination, and relays TLS packets between
> the 2 connections. TCP is hop by hop, TLS is end to end, examining TCP
> sequence numbers and ACKs does not reveal the hidden leg of the service.
> Suppose that I build a QUIC proxy that accepts UDP packets at port 4433,
> and then does pretty much the same job as load balancer: look for the
> (possibly encrypted) SNI inside the client hello for initial packets;
> look for the destination connection ID in other packets; forward the UDP
> packets to the hidden server based on that, and vice versa in the other
> direction. This is sort of equivalent to the TCP/TLS proxy scenario: UDP
> is hop by hop; QUIC and TLS is end to end. The QUIC messages are
> encrypted and don't reveal much, but the spin bit will reveal the
> end-to-end RTT.

I guess this shows that some privacy is lost with the spin bit enabled. 
When writing a proxy you may put some more effort and provide a TOR like 
proxy where the outer QUIC connection is only to the proxy and a inner 
QUIC connection is end to end.


> Of course, examining the content and timing of packets might in both
> cases reveal the end-to-end RTT, but layering makes a difference. The
> application may be able to implement end-to-end measures to counter the
> analysis of end-to-end traffic, but the application cannot easily
> influence the spin bit.
> -- Christian Huitema