RE: Read-out on offline connection ID discussion

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 25 January 2018 00:12 UTC

Return-Path: <ilubashe@akamai.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 DF72F12D835 for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 16:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 6_wTQVF4H0Nn for <quic@ietfa.amsl.com>; Wed, 24 Jan 2018 16:12:48 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 AAF9912D831 for <quic@ietf.org>; Wed, 24 Jan 2018 16:12:48 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0P0CVV9015766; Thu, 25 Jan 2018 00:12:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=R6UKuBeNwjaJNqov52IAN5xxxYIGCUPdW0ZBWvRrP30=; b=jsn04mvdXQv9kQVkvcUgcs+Goa9Mo2HFs8kHFThovEWqlq05EBF2yLoFVyYU6b9Zj2h8 iJ2CxAl8kOPKhZ6EwlwRhazundcE1wZ9zjU06PWyIEspCKvUuQ3AFw5vPrSDbLcKUObw igtIikmsZavI0fov9Ulo35bY54QA1V+kggf0cuF4JODJIe8xL57mm20N6vzQABzw3Gvs G6ev8RVn+dViBFjhpSyEYteRyMVXO0l9Sb/hmETaKL1KC+RPiYfyBXiO4CJDj+f7ELy5 ROW1OgRkczgAPA4OPzyUAZwiKCDwa7WtM3dQumgOOjZh587YVKR7/mKTUVqVT9BsS6Gg FA==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgwxmn9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 00:12:31 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0P0AXRP023220; Wed, 24 Jan 2018 19:12:30 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200n2jw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 19:12:30 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 Jan 2018 19:12:28 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 24 Jan 2018 19:12:28 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Roberto Peon <fenix@fb.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: AQHTlWPu47NFt37BOUi/Ui44cVLNBqOD9KiAgAAHCICAAAKWAP//sUHQgABWAwD//67rUA==
Date: Thu, 25 Jan 2018 00:12:28 +0000
Message-ID: <f35d6dfb1fa9460fb623c0cae028fe56@usma1ex-dag1mb5.msg.corp.akamai.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>
In-Reply-To: <DM5PR1501MB218377CAC296DA62336310DDCDE20@DM5PR1501MB2183.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.239]
Content-Type: multipart/alternative; boundary="_000_f35d6dfb1fa9460fb623c0cae028fe56usma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=711 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250001
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=653 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250001
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Rv1idX-tWXjZzJGk5MTB81xKgIc>
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:12:51 -0000

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