Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

"Brian Trammell (IETF)" <ietf@trammell.ch> Fri, 06 April 2018 07:16 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F2126CE8 for <quic@ietfa.amsl.com>; Fri, 6 Apr 2018 00:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK7kX4-Mp1uU for <quic@ietfa.amsl.com>; Fri, 6 Apr 2018 00:16:36 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3792E126C26 for <quic@ietf.org>; Fri, 6 Apr 2018 00:16:36 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D4A65340D7A; Fri, 6 Apr 2018 09:16:33 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.14077); Fri, 6 Apr 2018 09:16:33 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 09:16:33 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50820116; Fri, 06 Apr 2018 09:16:33 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_79C6A98C-4F4E-482F-92F3-9F85EA4F530E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Date: Fri, 06 Apr 2018 09:16:32 +0200
In-Reply-To: <CABkgnnWAgGJaKs8teKTURiNDRA61fRhN6pxYQuD1MbkPDqasKQ@mail.gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Frederick Kautz <fkautz@alumni.cmu.edu>
To: Martin Thomson <martin.thomson@gmail.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net> <CABkgnnWAgGJaKs8teKTURiNDRA61fRhN6pxYQuD1MbkPDqasKQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wwLSgr-YstXRwZMZpP6XwhgZjdw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 07:16:39 -0000

(Repeating and expanding my comment on #1269 to the list)

+1 to CID rotation being pointless if we don't do this. However, this seems dangerous if not done carefully, and it links CID rotation rate to the maximum usable UDP port consumption rate, which is (most probably) widely variable across access networks and (AFAICT) largely unknown in the literature. We have anecdata here, and we need data.

Note that QUIC presently doesn't have an advisory on-path state clearance signal (we hsd discussed this as a signal bound to public reset in #20, but it morphed into Stateless Reset, which has completely different semantics), which means that there is neither a present nor yet a potential future method to reduce the NAT state load this will generate.

I'd feel a lot less apprehensive about this if there were an advisory, integrity-protected signal meant for path consumption to clear state for a path. Of course it wouldn't be used at all on day one, but the tradeoff it presents is "hey, this is QUIC, it will burn through your UDP port state faster than any other UDP protocol and multiplicatively faster than TCP; but hey look, you can clear state when you see this path-verifiable singal to reduce the impact this has."

Cheers,

Brian

> On 6 Apr 2018, at 02:38, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <huitema@huitema.net> wrote:
>>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu> wrote:
>>> 
>>> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation?
>> 
>> Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently.
> 
> This seems like a simple fix, particularly since Mike recently added
> text that suggests occasional use of new connection IDs.  In the
> spirit of keeping the wheels greased:
> 
> https://github.com/quicwg/base-drafts/pull/1269
>