Re: Packet number encryption
"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 31 January 2018 09:59 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 06264131B9C for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 01:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_TP6CJnJB6r for <quic@ietfa.amsl.com>; Wed, 31 Jan 2018 01:59:50 -0800 (PST)
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 30B41131AEA for <quic@ietf.org>; Wed, 31 Jan 2018 01:54:54 -0800 (PST)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB38340EA6; Wed, 31 Jan 2018 10:54:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6029); Wed, 31 Jan 2018 10:54:50 +0100 (CET)
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; Wed, 31 Jan 2018 10:54:49 +0100 (CET)
Received: from [81.134.152.4] (account ietf@trammell.ch HELO [172.18.9.171]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43870581; Wed, 31 Jan 2018 10:54:49 +0100
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <07021975-8E71-4602-A98B-27E33DAE6A28@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_F2A7FFDB-AE84-4B0D-92F0-C070E221BA60"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Packet number encryption
Date: Wed, 31 Jan 2018 09:54:51 +0000
In-Reply-To: <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com>
Cc: QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/F-vPqGk0NEtGPRXJa-tVCOVlZBo>
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: Wed, 31 Jan 2018 09:59:55 -0000
> On 30 Jan 2018, at 20:31, Eric Rescorla <ekr@rtfm.com> wrote: > > > > On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <ietf@trammell.ch> wrote: > hi Martin, > > Thanks for the PR. > > > On 30 Jan 2018, at 01:59, Martin Thomson <martin.thomson@gmail.com> wrote: > > > > Here's a PR: > > > > https://github.com/quicwg/base-drafts/pull/1079 > > > > In short, this builds on Kazuho's excellent suggestion to use ECB-mode > > to protect the packet number. It does this only slightly differently, > > using suggestions from ekr and others to allow for cryptographic > > agility and use of primitives that match the negotiated AEAD. > > > > In short, it takes some of the ciphertext of the packet payload, and > > uses that to encipher the packet number. My intuition is that this is > > pretty solid, but I want to check if the working group is happy that > > this is generally OK before seeking cryptographic review. > > > > For instance, the requirement for side-channel resistance is already > > controversial: https://github.com/quicwg/base-drafts/pull/1079/files#r164588705 > > > > For the record, I doubt that this can be proven to be secure without > > both breaking new ground and adding some constraints to the AEADs that > > we use. And that's before we get into actual breaks on the technique > > that I'm too thick-headed to think of. In any case, we're relying on > > this to protect against linkability, so I'd like to ensure that we're > > not completely crazy in doing so. > > I'm not sure this isn't completely crazy. > > Our model for linkage attacks seems a little too fuzzy to me to be useful for evaluating whether this proposal is an improvement on the status quo. Of course, there's an inherent tension among the identifiability of flows by 5-tuple, the explicit identifiability of flows by CID (which we'll work to remedy at the same time as we stick more bits in the CID, apparently), and the desire for two independent 5-tuple flows to remain unlinkable. So this is inherently hard, because we don't have internally consistent set of requirements for linkability support and avoidance. > > Beyond this, though, we need to have a coherent idea of what we're trying to prevent. From discussions to date, I think these are the two cases we care about: > > (1) An unprivileged on-path device that sees a packet from a flow that is migrated on purpose by an endpoint (i.e., due to connection migration or multipath) should not be able to associate that packet to the prior flow. > > (2) An unprivileged on-path device that sees a packet from a flow that is unintentionally migrated (i.e., one of its globally routable addresses changes without the associated endpoint's knowledge) should not be able to associate that packet to the prior flow. > > In the presence of any connection ID that has enough entropy to be used for load balancing, linkability avoidance in case 2 is impossible. Indeed, the CID exists in part to *allow* linkability in case 2. Any packet number encryption approach is necessarily useless for linkability avoidance in this case, unless the CID is also protected with a secret known only to the endpoints and the load-balancer. We'll see where the CID DT lands here. > > When the connection ID is absent or protected, and the packet number is encrypted, case 2 is still problematic. In an unintentional migration, only two values in the five-tuple change, and it's impossible to make the first packet sent from the migrated endpoint to the non-migrated endpoint look like a handshake packet. So to find an unintentional migration, an observer only needs to look for all flows toward a 3-tuple without being preceded by a valid handshake that started within 30 seconds of another one ending on the same 3-tuple. Even for very large load balancers, this is not a giant anonymity set. > > If you believe that greasing functions over packet numbers is necessary -- I'm not sure I do, but that's a different, future message -- then this proposal might be useful for that, but if linkability prevention is the goal, I'm not convinced it's fit for purpose. > > This proposal also opens a trivial class of wasted-work attacks against QUIC servers by malicious clients, which can now craft packets which will require the server to partially decrypt them before realizing they're not useful. Obviously bad packet numbers can be avoided with simple heuristics. Less-obvious attacks might be crafted to incur significant nonproductive cost on the server side. This seems to be an unavoidable property of any approach to packet number encryption that would actually work, though, so that's not an observation about this specific proposal. I also haven't done the analysis to see if this is all that bad. > > Why isn't this already the case? I just take a valid packet, change a bit in the MAC, and resend it a bunch of times. It seems to me that the borked MAC replay is easy to distinguish and dynamically filter at the receiver: if you see this, someone is screwing with you, and you can safely blackhole them. On the other hand, a stream of packets that look valid to the decryption stage but that will be rejected as irrelevant but not insane seems harder to reject and blackhole in the general case Cheers, Brian > -Ekr > > > Note as well that this proposal comes with a manageability cost. On-path measurement of upstream loss and reordering would become impossible, and the fidelity of the spin bit under loss and reordering would be reduced. > > > In case people were wondering, and because it already came up: I > > intend to separately propose a change to the short header packet that > > would remove the type field and move the packet number length under > > encryption. See my response to Ian's question on the PR for an > > explanation of how this will likely work. > > Yep, this makes sense. We'll need to consider these changes closely in concert with any change to the CID. As above, avoiding linkability with PN encryption while aiding it with a CID is hard, and a varlen CID plus a varint encrypted PN will make parsing fiddlier than it already is. > > As Christian noted, using the short header type field to provide a sort of subsequence number or other packet-number independent explicit signal would mitigate the damage packet number encryption would to do loss and reordering observability, but not completely address them. > > Cheers, > > Brian > >
- Packet number encryption Martin Thomson
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Eggert, Lars
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Ted Hardie
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Martin Duke
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Dmitri Tikhonov
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Piotr Galecki
- Re: Re: Packet number encryption alexandre.ferrieux
- Re: Packet number encryption Patrick McManus
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Roberto Peon
- RE: Packet number encryption Piotr Galecki
- RE: Packet number encryption Roni Even (A)
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Lubashev, Igor
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Lubashev, Igor
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Fossati, Thomas (Nokia - GB/Cambridge)
- Re: Packet number encryption Stephen Farrell
- Re: Packet number encryption Willy Tarreau
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Brian Trammell (IETF)
- Reducing ossification through protocol design (wa… Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Roberto Peon
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Jana Iyengar
- RE: Packet number encryption Roni Even
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Roberto Peon
- Re: Reducing ossification through protocol design… Gorry Fairhurst
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- RE: Packet number encryption Roni Even (A)
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- Re: Reducing ossification through protocol design… Salz, Rich
- Re: Reducing ossification through protocol design… Mirja Kühlewind
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Reducing ossification through protocol design… Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Jana Iyengar
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Ted Hardie
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Marten Seemann
- RE: Packet number encryption Roni Even (A)
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Brian Trammell (IETF)
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Gorry Fairhurst
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- Explicit measurability in the QUIC wire image (wa… Brian Trammell (IETF)
- RE: Explicit measurability in the QUIC wire image… Roni Even (A)
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Stephen Farrell
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Jana Iyengar
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Martin Thomson
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Christian Huitema
- Re: Packet number encryption Marten Seemann
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Martin Thomson
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mirja Kühlewind
- Re: Explicit measurability in the QUIC wire image… Mikkel Fahnøe Jørgensen
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Brian Trammell (IETF)
- RE: Packet number encryption Praveen Balasubramanian
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Christian Huitema
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Explicit measurability in the QUIC wire image… Kazuho Oku
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- Re: Packet number encryption Christian Huitema
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mike Bishop
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Eric Rescorla
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- Re: Packet number encryption Ian Swett
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption David Benjamin
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Deval, Manasi
- RE: Packet number encryption Deval, Manasi
- Re: Packet number encryption Victor Vasiliev
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Ian Swett
- Re: Packet number encryption Ian Swett
- Re: Packet number encryption Martin Thomson
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- RE: Packet number encryption Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- Re: Packet number encryption Salz, Rich
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: hardware offload (was: Packet number encrypti… Christian Huitema
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: hardware offload (was: Packet number encrypti… Eggert, Lars
- RE: Packet number encryption Praveen Balasubramanian
- RE: hardware offload (was: Packet number encrypti… Praveen Balasubramanian
- RE: Packet number encryption Praveen Balasubramanian
- RE: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Victor Vasiliev
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Kazuho Oku
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen
- Re: Packet number encryption Mikkel Fahnøe Jørgensen