RE: Privacy holes
Praveen Balasubramanian <pravb@microsoft.com> Thu, 12 April 2018 01:46 UTC
Return-Path: <pravb@microsoft.com>
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 8163612D876 for <quic@ietfa.amsl.com>; Wed, 11 Apr 2018 18:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 xXXdFSO_RAbK for <quic@ietfa.amsl.com>; Wed, 11 Apr 2018 18:46:43 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0093.outbound.protection.outlook.com [104.47.42.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1CD1243F6 for <quic@ietf.org>; Wed, 11 Apr 2018 18:46:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uG1pkIegN2yvYxPOoUqKRK3/+oiWlsVZ62GAOlZujio=; b=FyB88Wac0bQsrcFMbXhhs/9O1yYxSkt72Ls/YGR9nHbAyz1Cz0af89AG679Hca2uoz76OGPeVzUZwuVjyw7bynoC50KtGeW3IoUg0w91j5kJzOJqYM48BCRIsJqjSZYsGxezakgcCzEkAKiS8/q06cOKvEAPfZy7xTSehmcwtQY=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.3; Thu, 12 Apr 2018 01:46:41 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::6d48:f7af:d267:2021%6]) with mapi id 15.20.0696.006; Thu, 12 Apr 2018 01:46:41 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: huitema <huitema@huitema.net>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: Privacy holes
Thread-Topic: Privacy holes
Thread-Index: AQHT0fPCjE+2yJJX1kG/ZO2j/ihAdaP8RCzQ
Date: Thu, 12 Apr 2018 01:46:41 +0000
Message-ID: <MWHPR21MB063834642A3214939823CD84B6BC0@MWHPR21MB0638.namprd21.prod.outlook.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <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> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CY4PR21MB063098C907E732B0384B2824B6BE0@CY4PR21MB0630.namprd21.prod.outlook.com> <DM5PR2101MB0901E6C75EDCFDA209714D89B3BE0@DM5PR2101MB0901.namprd21.prod.outlook.com> <CY4PR21MB0630A6C5D63C175F390CC650B6BD0@CY4PR21MB0630.namprd21.prod.outlook.com> <4eb09bd5-0a5c-6cc5-6b15-ad05b162ff93@huitema.net>
In-Reply-To: <4eb09bd5-0a5c-6cc5-6b15-ad05b162ff93@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:3::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0125; 7:1qmLduykqA4qeH96HSrOQMmXWzxwzQr/4W4T8slaJgx650hjs/iENf8vudp9C98lWra3vd3CSl/X+cNfZbw5qtKQmu6gy6ZfN23dVaavMpMWVz2kxuHJq1jJekBXOtMosISXFfbs+K5bQrASff9bZv/kcjC7r048SKuzrzwVIiAp5dCRG9YGWqVgJmB6zD41GC7UxVKoSKs8cfcwUHMOfBmasrZyvkjKtMZNttY1wl8U2Oou+F6hhSU3sdU2xxvW; 20:U/d5fmaptOdFDCv/0KTKdB5s9Yu8Yh8hChbN4EsMWpR6jjlOtjvjOsEqLo22yXfrHOIG1oBLtf+K4CGBkbQ/CdS0M3lM9OehaRe1jC54oitpTQlR7jG2/OG6fBgQt8ukZ8E5UIRXt2ycRycjY3fsiB9ghdqBg5EJv9OJB1thjPQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(3008032)(2017052603328)(7193020); SRVR:MWHPR21MB0125;
x-ms-traffictypediagnostic: MWHPR21MB0125:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <MWHPR21MB0125707006F0B2DEA4A9FF8EB6BC0@MWHPR21MB0125.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501343)(52105095)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR21MB0125; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0125;
x-forefront-prvs: 06400060E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(39380400002)(346002)(396003)(13464003)(189003)(199004)(9686003)(3480700004)(8936002)(8676002)(25786009)(81156014)(81166006)(97736004)(53936002)(478600001)(105586002)(446003)(2906002)(55016002)(3660700001)(3280700002)(68736007)(7116003)(6116002)(106356001)(6436002)(5250100002)(2501003)(6246003)(10290500003)(5660300001)(74316002)(33656002)(86362001)(110136005)(221733001)(305945005)(22452003)(186003)(7736002)(316002)(86612001)(229853002)(93886005)(14454004)(11346002)(476003)(486006)(2900100001)(102836004)(76176011)(10090500001)(99286004)(46003)(8990500004)(7696005)(6506007)(59450400001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0125; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3af3ad2a-9725-40cb-927e-08d5a0173d54
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3af3ad2a-9725-40cb-927e-08d5a0173d54
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2018 01:46:41.2687 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0125
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/a1tx7fKOjx53VDUqiKQeeHpD46s>
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, 12 Apr 2018 01:46:45 -0000
It's not just the server information. Its timing information that is far more valuable for the adversary. Not all clients will failover from wifi to cellular at the same time and hence the correlation will be very strong. You just need a few failover events in a day for a very strong correlation. What also makes this easy is that In a capture, a migration looks very different than a new connection. The attack seems very practical for a powerful adversary. >> I don't like the general line of reasoning that "because there is another hole here, we should not fix this hole there." I didn't state this and incremental progress is useful. I was simply trying to list possible privacy holes since that was the question on this thread. >> we can start using multiple addresses per server, or maybe some form of onion routing, or some CDN trick In an ideal world yes. But most deployments will be incremental on current infra. >> But if we stick a clear text ID in the headers, we lose This is too broad - sticking the *same* cleartext ID is a problem. Different cleartext IDs is no different than using encryption i.e. make clear text fields look like a new connection on the wire. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, April 11, 2018 5:17 PM To: quic@ietf.org Subject: Re: Privacy holes On 4/11/2018 12:18 PM, Praveen Balasubramanian wrote: > Going back to Christian's original question on privacy holes, there is an attack for linking IP addresses in the voluntary migration case. > > Let's consider the parking lot problem or in general case losing one network and roaming to another network. This is the primary use case for connection migration. In this case all active QUIC connections that can migrate, will do so. When these connections migrate they can change the CID, the local port number and packet numbers. However do notice that only the local 2-tuple changes for each connection, the server's 2-tuple remains the same. > > Let's assume a powerful adversary can collect a network sniff of all this traffic and builds a massive dataset. The adversary can then run a machine learning algorithm to identify time instants where a bunch of connections change their local 2-tuple at near the same time instant but continue going to the same server side 2-tuples. This will allow the adversary to link two IP addresses. The more times the user roams between networks back and forth the richer the correlation. The more open connections to different servers, the richer the correlation. Geolocation information can minimize the number of addresses the adversary needs to correlate. > > The fundamental problem seems to be that the substrate is UDP/IP and it is in the clear and allows linkability. The server 2-tuple does provide some information, but we should not overstate it. One element of the 2-tuple, the port number, is likely to be set to 443 for pretty much all servers, so I don't think it is terribly useful. The IP address is useful, but in many cases these address will be shared by a large number of connections, either because it is a big service like Microsoft.com, or because it ends in some kind of CDN. I don't like the general line of reasoning that "because there is another hole here, we should not fix this hole there." If you accept that, you end up with so many unpatched holes that the situation is indeed hopeless. But if we fix now the holes that we can fix, and if other holes prove important, we can fix them later. For example, if tracking by IP is an important problem, we can start using multiple addresses per server, or maybe some form of onion routing, or some CDN trick. But if we stick a clear text ID in the headers, we lose. -- Christian Huitema
- Hardware acceleration and packet number encryption Christian Huitema
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Kazuho Oku
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Kazuho Oku
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Subodh Iyengar
- Re: Hardware acceleration and packet number encry… Eric Rescorla
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Christian Huitema
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Ian Swett
- Re: Hardware acceleration and packet number encry… Christian Huitema
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Salz, Rich
- Re: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- Re: Hardware acceleration and packet number encry… Ian Swett
- RE: Hardware acceleration and packet number encry… Swindells, Thomas (Nokia - GB/Cambridge)
- RE: Hardware acceleration and packet number encry… Deval, Manasi
- Re: Hardware acceleration and packet number encry… Christian Huitema
- Re: Hardware acceleration and packet number encry… Jana Iyengar
- Re: Hardware acceleration and packet number encry… Ian Swett
- Re: Hardware acceleration and packet number encry… Watson Ladd
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- RE: Hardware acceleration and packet number encry… Mikkel Fahnøe Jørgensen
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- Re: Hardware acceleration and packet number encry… Mark Nottingham
- RE: Hardware acceleration and packet number encry… Praveen Balasubramanian
- Getting to consensus on packet number encryption Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Willy Tarreau
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- RE: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Willy Tarreau
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- ECN signaling from userland Re: Getting to consen… Lars Eggert
- Re: ECN signaling from userland Re: Getting to co… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… alexandre.ferrieux
- Re: Getting to consensus on packet number encrypt… Eric Rescorla
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- Re: Getting to consensus on packet number encrypt… Philipp S. Tiesel
- Privacy holes (was: Re: Getting to consensus on p… Christian Huitema
- Re: Privacy holes (was: Re: Getting to consensus … Frederick Kautz
- Re: Privacy holes (was: Re: Getting to consensus … Christian Huitema
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Privacy holes Gorry Fairhurst
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Mike Bishop
- RE: Privacy holes (was: Re: Getting to consensus … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Praveen Balasubramanian
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- RE: ECN signaling from userland Re: Getting to co… Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Frederick Kautz
- Re: Privacy holes (was: Re: Getting to consensus … Willy Tarreau
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Privacy holes (was: Re: Getting to consensus … Lubashev, Igor
- Re: Privacy holes (was: Re: Getting to consensus … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Brian Trammell (IETF)
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes (was: Re: Getting to consensus … Brian Trammell (IETF)
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Grips in the Wire Image for In-Network State (was… Brian Trammell (IETF)
- Re: Grips in the Wire Image for In-Network State … Mikkel Fahnøe Jørgensen
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Privacy holes Roland Zink
- Re: Grips in the Wire Image for In-Network State … Kazuho Oku
- Re: Grips in the Wire Image for In-Network State … Martin Thomson
- Re: Grips in the Wire Image for In-Network State … Brian Trammell (IETF)
- Re: Grips in the Wire Image for In-Network State … Brian Trammell (IETF)
- Re: Privacy holes Ian Swett
- Re: Grips in the Wire Image for In-Network State … Spencer Dawkins at IETF
- Re: Grips in the Wire Image for In-Network State … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Grips in the Wire Image for In-Network State … Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Bona fide loss measurement bits alexandre.ferrieux
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Roberto Peon
- RE: Privacy holes (was: Re: Getting to consensus … Praveen Balasubramanian
- Re: Privacy holes Christian Huitema
- RE: Privacy holes Praveen Balasubramanian
- Re: Privacy holes (was: Re: Getting to consensus … Ian Swett
- Re: Privacy holes (was: Re: Getting to consensus … Kazuho Oku
- Re: Privacy holes (was: Re: Getting to consensus … Martin Thomson
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Privacy holes (was: Re: Getting to consensus … Mike Bishop
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Mark Nottingham
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- RE: Getting to consensus on packet number encrypt… Deval, Manasi
- Re: Getting to consensus on packet number encrypt… Jana Iyengar
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Mike Bishop
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Erik Kline
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Patrick McManus
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Kazuho Oku
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- Re: Getting to consensus on packet number encrypt… Jana Iyengar
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- Re: Getting to consensus on packet number encrypt… Boris Pismenny
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Ian Swett
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Martin Thomson
- Re: Getting to consensus on packet number encrypt… Benjamin Kaduk
- Re: Getting to consensus on packet number encrypt… Salz, Rich
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Brian Trammell (IETF)
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- Re: Getting to consensus on packet number encrypt… Ted Hardie
- RE: Getting to consensus on packet number encrypt… Lubashev, Igor
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: Getting to consensus on packet number encrypt… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Roberto Peon
- Re: [Potential Spoof] Re: Getting to consensus on… Jana Iyengar
- RE: [Potential Spoof] Re: Getting to consensus on… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Spencer Dawkins at IETF
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: [Potential Spoof] Re: Getting to consensus on… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Benjamin Kaduk
- Re: Getting to consensus on packet number encrypt… Ian Swett
- Re: Getting to consensus on packet number encrypt… Mirja Kühlewind
- RE: Getting to consensus on packet number encrypt… Roni Even (A)
- Re: Getting to consensus on packet number encrypt… Dmitri Tikhonov
- Re: Getting to consensus on packet number encrypt… Gorry Fairhurst
- RE: Getting to consensus on packet number encrypt… Praveen Balasubramanian
- Re: Getting to consensus on packet number encrypt… Christian Huitema
- Re: Getting to consensus on packet number encrypt… Mikkel Fahnøe Jørgensen
- Re: Getting to consensus on packet number encrypt… Christian Huitema