IETF Logo Mail Archive

Re: Read-out on offline connection ID discussion

Roberto Peon <fenix@fb.com> Thu, 25 January 2018 00:20 UTC

Return-Path: <prvs=45637dce38=fenix@fb.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 B65E512D831 for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 16:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=dXB2y1xi; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Y7Ok2lMj
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 jvxXwDZXX_ZG for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 16:20:46 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 42EC31200C1 for <quic@ietf.org>; Wed, 24 Jan 2018 16:20:46 -0800 (PST)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0P0J15b026222; Wed, 24 Jan 2018 16:20:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=zcQ4KkWJ6Iq0hNaS0VyS/DTnmMQKnwtlUPcvwckuL6Q=; b=dXB2y1xitN8nQ2/XkJc9Wt6LNTkQb1CZFuvrCiO8wYL2KvF/miWfgFW8zbdcfGT6AMXv 5YjKnrdinBCgm0OqVtSFu+nJIO5IwfPfg/QxF4iV03f926/+1wGeJDjFpruaP3Ir1Vna RZSHLeCpqVixJPWULrXJu2QVtlZUe6TWJZo=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fq1sw8ker-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jan 2018 16:20:36 -0800
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 24 Jan 2018 19:20:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zcQ4KkWJ6Iq0hNaS0VyS/DTnmMQKnwtlUPcvwckuL6Q=; b=Y7Ok2lMjTQCKYvPkDpDjIUhdARQXagtQClLu+sfhk+NrrTRJl0XxTjH6i+eac/tP0CCqjeHjB0htKFGCmHL+XhwBfJtdEmT6acXvkXIbFsq4si/WIaU2w/E7+TnZz/sC+RrlPWPicSQoGw7Tjkl5WLzoVjzYmcMvgJRKRXMad88=
Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.18; Thu, 25 Jan 2018 00:20:31 +0000
Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Thu, 25 Jan 2018 00:20:31 +0000
From: Roberto Peon <fenix@fb.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>, Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: Re: Read-out on offline connection ID discussion
Thread-Topic: Read-out on offline connection ID discussion
Thread-Index: AQHTlWQIcw/rnBpHIU2EI+BcfJeacaODoNeAgAAHCICAAAKVAIAABdAAgAAAnceAAAa1AIAAAMqW
Date: Thu, 25 Jan 2018 00:20:31 +0000
Message-ID: <DM5PR1501MB21832F46144D4149CBCD17BDCDE10@DM5PR1501MB2183.namprd15.prod.outlook.com>
References: <CABcZeBO8UcdsPPp7D-3gZW8tuDqNhP-z+O1+WH=68KjbfYMr5A@mail.gmail.com> <CAN1APdewkGQULckLb6F4rEzcPtiFJPBVBQbkcNeupK3d+r6Sow@mail.gmail.com> <CABcZeBO2iRrFXNgLD1AsxmwRJ+Pz6USadWGeU5vb12Pu9eOyog@mail.gmail.com> <da03a2b1-5b81-338d-4e7b-5fd7dd0aeab6@huitema.net>, <04b6b53ef8f7490bbbfb03c3526022f8@usma1ex-dag1mb5.msg.corp.akamai.com> <DM5PR1501MB218377CAC296DA62336310DDCDE20@DM5PR1501MB2183.namprd15.prod.outlook.com>, <f35d6dfb1fa9460fb623c0cae028fe56@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <f35d6dfb1fa9460fb623c0cae028fe56@usma1ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.170.5.21]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2183; 7:2g/vNvd/qtjmFTGHj2v2wRPMYaY0VIypYtc9gCStHuL0xd2YpbwchZB7oM1t1oApZAGnafD/OAC5OXF6PLF/qZIa2GAJ8GyjtgH2Dk6ZLq/IO22Z6UkZxizz5wrNRAIPHubD77Rj1Q92DxodcmI5neTycd16ty/Pr0AIv8fcapb28uBkYRy+BGG1cR1ramqXrb+4aIG5SIKhvr4QqOkvOUlGd/lu+T5wjIC4vo/xJGtKIt9LTXzu1T4oTWDb5krR; 20:tdjxwIvmr+wh2e5CDfR96n5c9ITvoppyASR3vtQZKCZRyeIonq3XedND66GIbxqSDfNDWMSmeZy/oD2xH10YsXU9oAdcmxyeKT/NdXZCoV8fv1iqAUDXrbtNtHD0PqBV4oJ/w3/qpFn/UaxyBV1XvPt3fEULaP/XPj7yu+74q0g=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 4ef51c72-ba94-4f1c-97ee-08d563897222
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2183;
x-ms-traffictypediagnostic: DM5PR1501MB2183:
x-microsoft-antispam-prvs: <DM5PR1501MB2183CD7193A880FFB4D60B91CDE10@DM5PR1501MB2183.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(67672495146484);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(11241501184)(2400081)(944501161)(3002001)(6041288)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR1501MB2183; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2183;
x-forefront-prvs: 0563F2E8B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(376002)(396003)(346002)(39380400002)(366004)(13464003)(199004)(189003)(478600001)(6116002)(81156014)(8936002)(33656002)(99286004)(81166006)(316002)(110136005)(68736007)(3660700001)(229853002)(53936002)(93886005)(39060400002)(8676002)(4326008)(6436002)(105586002)(186003)(2906002)(3846002)(2900100001)(54896002)(97736004)(7696005)(2950100002)(6246003)(3280700002)(19627405001)(5660300001)(5250100002)(6606003)(26005)(86362001)(106356001)(74316002)(7736002)(59450400001)(66066001)(25786009)(53546011)(6506007)(9686003)(102836004)(76176011)(236005)(14454004)(55016002)(42262002)(19627235001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2183; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 1ccMDF1DJAgtntFTjQQKH2F3hB5mrTo0euzUePGnWIA3syTuzgnUnRtqpGmYR5BeHZ4HILNzUP5zXSDM55qL/w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR1501MB21832F46144D4149CBCD17BDCDE10DM5PR1501MB2183_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ef51c72-ba94-4f1c-97ee-08d563897222
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 00:20:31.7926 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2183
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OtO8LBUz7jy8UjQFcrhavZqfYy8>
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, 25 Jan 2018 00:20:49 -0000

I suspect you mean the 5-tuple, and not just the server IP, as that leaks more information.

I agree that (the 5-tuple and/or server address) gives away information.
I suspect it makes it somewhat more difficult. Once multipath and/or 5-tuple migration is available, the combinations of 5-tuple plus CID changes does provide some substantial improvements.

Regardless, it is certainly helpful to prevent ossification, which is what I was commenting on.
-=R

________________________________
From: Lubashev, Igor <ilubashe@akamai.com>
Sent: Wednesday, January 24, 2018 4:12:28 PM
To: Roberto Peon; Christian Huitema; Eric Rescorla; Mikkel Fahnøe Jørgensen
Cc: IETF QUIC WG
Subject: RE: Read-out on offline connection ID discussion


If you are worried that the client’s privacy can be compromised by CIDs linkable to the same server, I’d be worried that server’s IP will give this away even more reliably.



  *   Igor



From: Roberto Peon [mailto:fenix@fb.com]
Sent: Wednesday, January 24, 2018 6:51 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema <huitema@huitema.net>; Eric Rescorla <ekr@rtfm.com>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Read-out on offline connection ID discussion



Imagine allowing the server to send multiple CIDs, and provide the server with some revocation mechanism (TTL or explicit, or what-have-you).

A client may use any of these CIDs until they are revoked.

Thus, a server which cares to prevent ossification could provide multiple CIDs, and the client could switch between them on a per-packet basis.

-=R

________________________________

From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>
Sent: Wednesday, January 24, 2018 3:46:16 PM
To: Christian Huitema; Eric Rescorla; Mikkel Fahnøe Jørgensen
Cc: IETF QUIC WG
Subject: RE: Read-out on offline connection ID discussion



> But I am concerned that the specific length, and maybe the clear text prefixes of a CID, can be used for fingerprinting, and then provide linkability.

I would expect non-trivial things to CIDs done by servers in client-server scenarios, so you are fingerprinting the server, not the client.  Ae you concerned with a p2p case?

- Igor

-----Original Message-----
From: Christian Huitema [mailto:huitema@huitema.net]
Sent: Wednesday, January 24, 2018 6:25 PM
To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>>
Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: Re: Read-out on offline connection ID discussion

I get the argument for 16+n, var length, etc. But I am concerned that the specific length, and maybe the clear text prefixes of a CID, can be used for fingerprinting, and then provide linkability.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email