IETF Logo Mail Archive

RE: Asymmetric CIDs

Nick Banks <nibanks@microsoft.com> Fri, 16 February 2018 22:17 UTC

Return-Path: <nibanks@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 7B0CF1241F3 for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 14:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level:
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 lt-0U2sH2brD for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 14:17:12 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88A91200F1 for <quic@ietf.org>; Fri, 16 Feb 2018 14:17:12 -0800 (PST)
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=WiCM/beiEd2apuve4nsgOoJnvqD0IlVRUMZ1aS/2c2U=; b=jc7Dfpmu/IeuqrE2Ca2nACRodOsWp8vNy2GqTsf3qSuJCNv2huqn38OGJaWq7jIYQxpLxMAiURs2cRvHhuPzgQNiKDuWAZ/zRQXKAM2ZZyZPoxtkvUjngA/X24/CoR+nN9/anu2zyjiS4jFyw+08dGhB4XU0moayb0z2xs8Ct7E=
Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0755.namprd21.prod.outlook.com (10.173.204.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.2; Fri, 16 Feb 2018 22:17:10 +0000
Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0527.012; Fri, 16 Feb 2018 22:17:10 +0000
From: Nick Banks <nibanks@microsoft.com>
To: huitema <huitema@huitema.net>, Roberto Peon <fenix@fb.com>, Martin Duke <martin.h.duke@gmail.com>
CC: Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Subject: RE: Asymmetric CIDs
Thread-Topic: Asymmetric CIDs
Thread-Index: AQHTp0fnTbZXlaWDCkCz6gDW7l/HjKOnR9oAgAAHeYCAAAY3gIAAAxEAgAA+nwCAAAGy8A==
Date: Fri, 16 Feb 2018 22:17:10 +0000
Message-ID: <BN6PR21MB0178395DC04C19D991436525B3CB0@BN6PR21MB0178.namprd21.prod.outlook.com>
References: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com> <CAKcm_gOvf0N7sq2so38sQaD+2jHGnDpsSQHEwU8HPgSpMJRfzA@mail.gmail.com> <CAM4esxQW1-dVfJSi4zoURNV-7u0EP6h-Xdyx5Wbo0QMdrkLk=w@mail.gmail.com> <AA0705E2-7A79-47DD-846A-C0B74A8A4B24@huitema.net> <D7E469CD-B9D8-41ED-8F5C-9933DCBA90E6@fb.com> <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net>
In-Reply-To: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-16T22:17:08.8374342Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:4::4a5]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR21MB0755; 7:19sBvR2YTsKNlo4+/FJ52snSxHRc90wL4RDlNnl94V8p0zjSuFcg2rgGd8r5z9AtcaMRM9fG1p4vrO3UmQjk0EUuK64hYWHTxlRNq4OoBPRTVrzWCW5LB3ODFXsRUPfOCb5vOLvtYApI1VExWpwtY0i2/UcnMF1eJUsttSKeawK/Rizw5F9N3AzJM0q0Lu0GiRIrgiKp3wHhE7soeiFckROZ62iQqEyrU+wEiVpb6PVTkE7sP9yOsKn9ta5uEip7
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ec3a0f61-efab-4154-1faa-08d5758b0608
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:BN6PR21MB0755;
x-ms-traffictypediagnostic: BN6PR21MB0755:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <BN6PR21MB07552501BCFA665BBFFF6164B3CB0@BN6PR21MB0755.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001040)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231125)(944501161)(52105033)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR21MB0755; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0755;
x-forefront-prvs: 0585417D7B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(376002)(39860400002)(39380400002)(189003)(199004)(3480700004)(3280700002)(3660700001)(68736007)(93886005)(97736004)(6116002)(5660300001)(229853002)(2900100001)(4326008)(105586002)(25786009)(478600001)(790700001)(10290500003)(86612001)(86362001)(6346003)(76176011)(77096007)(102836004)(14454004)(53546011)(6506007)(2906002)(39060400002)(10090500001)(186003)(6246003)(53936002)(8990500004)(54906003)(110136005)(22452003)(99286004)(221733001)(7696005)(236005)(6436002)(9686003)(54896002)(55016002)(6306002)(316002)(7736002)(2950100002)(8676002)(81156014)(81166006)(8936002)(7116003)(33656002)(106356001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0755; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-microsoft-antispam-message-info: eKOKzl/FD8fnwWfBaYY0mm6oLm273hXO1PfFASArbBx2OrFEEJTClAxOdStt7Cc2t+87Mo+FpVPonpcmx87+KQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178395DC04C19D991436525B3CB0BN6PR21MB0178namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ec3a0f61-efab-4154-1faa-08d5758b0608
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 22:17:10.3491 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0755
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/frndko_mluDh2qmFFvopIlEuoYM>
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, 16 Feb 2018 22:17:15 -0000

Perhaps the client should send a NEW_CONNECTION_ID with the PATH_CHALLENGE and require the server to use that to respond.

- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Christian Huitema
Sent: Friday, February 16, 2018 2:10 PM
To: Roberto Peon <fenix@fb.com>; Martin Duke <martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>; Eric Rescorla <ekr@rtfm.com>
Subject: Re: Asymmetric CIDs


To be explicit, I am concerned by the following scenario:

1) Client sends a PATH CHALLENGE to server from a new client address with never-seen-before connection ID, obtained previously in NEW CONNECTION ID frame from server

2) Server respond by sending reply to new address with previously-negotiated-and-used CID of client.

3) Instant linkage.

The key is of course that the server picks a different CID to respond to the migration, normally in a NEW CONNECTION ID frame.

On 2/16/2018 10:25 AM, Roberto Peon wrote:
++ what Christian says.
The fact that it now takes two implementations to prevent linkability (either side messes it up, and that half-path is exposed, likely rendering it all exposed) is a bit sad.
-=R


From: QUIC <quic-bounces@ietf.org><mailto:quic-bounces@ietf.org> on behalf of Christian Huitema <huitema@huitema.net><mailto:huitema@huitema.net>
Date: Friday, February 16, 2018 at 10:16 AM
To: Martin Duke <martin.h.duke@gmail.com><mailto:martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett@google.com><mailto:ianswett@google.com>, IETF QUIC WG <quic@ietf.org><mailto:quic@ietf.org>, Eric Rescorla <ekr@rtfm.com><mailto:ekr@rtfm.com>
Subject: Re: Asymmetric CIDs

I like the concept, but I would like to understand how we avoid linkability on migration.
-- Christian Huitema

v2.23.0 | Report a Bug | By Email