IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Thu, 05 April 2018 15:34 UTC

Return-Path: <huitema@huitema.net>
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 242141277BB for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 08:34:34 -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, SPF_PASS=-0.001, 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 3kINTe_P8KRn for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 08:34:32 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7CD127601 for <quic@ietf.org>; Thu, 5 Apr 2018 08:34:32 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1f46uC-0001TY-B9 for quic@ietf.org; Thu, 05 Apr 2018 17:34:29 +0200
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1f46uA-0001Xa-QF for quic@ietf.org; Thu, 05 Apr 2018 11:34:27 -0400
Received: (qmail 3398 invoked from network); 5 Apr 2018 15:34:20 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.61]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mirja.kuehlewind@tik.ee.ethz.ch>; 5 Apr 2018 15:34:20 -0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <B0F49097-F77A-4831-B68B-4266AA880A86@tik.ee.ethz.ch>
Date: Thu, 05 Apr 2018 08:34:14 -0700
Cc: quic@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net>
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> <047d2ff0-ff8b-64c9-898 3-0ecabeb9fea5@huitema.net> <B0F49097-F77A-4831-B68B-4266AA880A86@tik.ee.ethz.ch>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: Privacy holes (was: Re: Getting to consensus on packet number encryption)
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5rg7rcCduaE0Xwo/tNK9mrl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVimHTpGI7nmuXHz2ru7+xXR87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWYO2/mqpOb7Q80SeXyngcEQspW6PWtFljIeoG6OsM9IZZbga7DcbM5 TlUJnsdZhmZgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6NV+QBQRtMmDe05Nd2KjhCWh+wlfAS2SbL4bvnSO/22WzpThgw5ICD+Lb xZm/MI4dOaYyGwgMwf9FTYaJWiXFxpRins15oKFWvUk5C9olBXB1qSIEae5DZ9cZ02JHi6IQw6nI oDr0sXUZ7YZoZ/GZ+gNl/9zCFdWYNKOuzgS95TNz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QPOq7XtrFrf6lvrXiM4x7dDjzRM>
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: Thu, 05 Apr 2018 15:34:34 -0000

 

> On Apr 5, 2018, at 2:26 AM, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> ...
> Timing doesn’t help here either because you still have the same destination IP, both port numbers and the fact that a migrated connection does not have a handshake. If we want to address the linkability problem, we would need to do much more, probably baring more hits on performance. 

Mirja,

You rightly point out that the connection ID and the Packet Number are not the only elements that provide linkability. There is also of course the UDP source port. That one is not much of an issue for servers, but it is an issue for clients. We are not spelling that out in the draft. We should, because clients can trivially close that hole when doing migration.

I am not sure that the absence of negotiation divulges much data. It marks the path as originating from a migration, but it does not tell from where. But there might be an ossification issue. We will get that ossification if we train middleboxes to believe that connection always start with an observable negotiation. So maybe we should explore ways to grease that.

Any other privacy hole that we should fix?

-- Christian Huitema

v2.14.0 | Report a Bug | By Email