IETF Logo Mail Archive

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

Mike Bishop <mbishop@evequefou.be> Thu, 05 April 2018 17:27 UTC

Return-Path: <mbishop@evequefou.be>
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 0360A126D3F for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=evequefou.onmicrosoft.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 cSATDvd7MhMT for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 10:27:13 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7A41271DF for <quic@ietf.org>; Thu, 5 Apr 2018 10:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NbWz/TLQfOrw7af6jkv74d2tlCFlNwag0eL8EslkR+w=; b=UzrrPctsa1L1ZICESIXoKD/I3D7teYDBtKya5spgVjNRXHdrzizxFX/T6R2ftWQlWIoKxhv/n20GYzQZgxG5Xjep4Piixp19upW4/7pBElvOitjYmzJQ/IKfjZ5dZyQ41/ygkc+luoGFuAa+4+TKhWIVcbpd3l4QqYYnrCkxPKg=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1391.namprd08.prod.outlook.com (10.162.1.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Thu, 5 Apr 2018 17:27:10 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::e9d8:1358:e716:ba77%13]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 17:27:10 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Kazuho Oku <kazuhooku@gmail.com>, Christian Huitema <huitema@huitema.net>
CC: IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Topic: Privacy holes (was: Re: Getting to consensus on packet number encryption)
Thread-Index: AQHTzPOeIdtMxyMgr0ikidMd5Tq1W6PyVBwAgAACsQCAABOkAIAAAGeQ
Date: Thu, 05 Apr 2018 17:27:10 +0000
Message-ID: <SN1PR08MB1854010FD61AC17D19E497FDDABB0@SN1PR08MB1854.namprd08.prod.outlook.com>
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> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net> <CANatvzy8zTFKs-c-rR0jMSHdh2HJMvZrRmcR5A+b6qNpNPzkrw@mail.gmail.com>
In-Reply-To: <CANatvzy8zTFKs-c-rR0jMSHdh2HJMvZrRmcR5A+b6qNpNPzkrw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1391; 7:JT58Me2LbrHlV5ysbvjQuBaMbO5dNCleitzrYX6IXoTGyHzi4t9Cz5rTnNq0QUxxdMsWeV8Lksl5S5nABO4FiPIhpSctbk9dB0eh9remIZ7aDK3r0EpXROEmYt4t/w/Osex2LV0F2PmNN4qjyt8tHMOU7a4ROxxIZiZsyguSLP2Zv4t7jE5a4aQYU1m1+2PqbT183BgK03zXKGkZHUg3wEa++g0EFk7v8LJjYdHlvYSi7of3j4sW792GPkWoQDYm
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 095c9d97-39ba-4968-79d5-08d59b1a7679
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1391;
x-ms-traffictypediagnostic: SN1PR08MB1391:
x-microsoft-antispam-prvs: <SN1PR08MB1391D76C88AE605C61697637DABB0@SN1PR08MB1391.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6041310)(2016111802025)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1391; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1391;
x-forefront-prvs: 06339BAE63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39830400003)(396003)(376002)(366004)(199004)(13464003)(189003)(377424004)(8676002)(2900100001)(7696005)(106356001)(76176011)(39060400002)(316002)(25786009)(5660300001)(81166006)(33656002)(486006)(3660700001)(81156014)(93886005)(99286004)(4326008)(229853002)(97736004)(6246003)(478600001)(790700001)(6116002)(3846002)(3280700002)(14454004)(186003)(55016002)(66066001)(6436002)(476003)(11346002)(446003)(5250100002)(2906002)(54906003)(8936002)(6506007)(53546011)(110136005)(7736002)(26005)(74316002)(53936002)(86362001)(74482002)(236005)(9686003)(6306002)(54896002)(68736007)(102836004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1391; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r5C4fX+SJFtqr6VOTuT25PvJfRx9gzw1Jd5rw3vlVN+tCvvOu4J2agaiOtqsocW17tUn5+st+CdnXDq9/aXLxWT9U11SQn5bM7xq9DJOWpwUop2CZLF18lOcsnHOMSgtO+dHSyXUgiCoN4e9y6AHy+T5M+0k9WA/a6UJI6jaMHrYLyP4zrE1wkuNFdtIHnovQHex1DSFmIYfq57UXHc1WCOSA+nvvzbXqkVHTQvAQRXfNLj+ndpFgIAaM19/c2xSaS41fyjiv9u8M9Njlx/GtcEry2HDyLXRNcXql5zl8rgMCRbq5zJv0zV9NBeSRnjjU/iydbkH6dz+lW9PmfijEdfLI97Kzr3m2/UgycAcjkhi6piNOqd5ZXsqxqTNTbATPuoY/gj37J7dtP5Zri5iqyhLq2A1SVmLeLBf/9qYZJs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR08MB1854010FD61AC17D19E497FDDABB0SN1PR08MB1854namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 095c9d97-39ba-4968-79d5-08d59b1a7679
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 17:27:10.0670 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1391
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gg0iH0RU37PgnMI8LK8t8XYIGQg>
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 17:27:17 -0000

Spec says:

An endpoint MUST NOT return to the send rate used for the previous path unless it is reasonably sure that the previous send rate is valid for the new path. For instance, a change in the client’s port number is likely indicative of a rebinding in a middlebox and not a complete change in path. This determination likely depends on heuristics, which could be imperfect; if the new path capacity is significantly reduced, ultimately this relies on the congestion controller responding to congestion signals and reducing send rates appropriately.



You're not required to reset the CWND if you have reason to believe the underlying path is the same, so doing this shouldn’t cause any transport information to get reset.



-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Kazuho Oku
Sent: Thursday, April 5, 2018 10:19 AM
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)



2018-04-06 1:08 GMT+09:00 Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>:

>

>

>> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <fkautz@alumni.cmu.edu<mailto:fkautz@alumni.cmu.edu>> wrote:

>>

>> Are you concerned that middleware boxes may be trained to reject migrations, thereby forcing a new connection with a visible negotiation?

>

> Yes. Hence the need to grease. For example, have clients do some gratuitous migration to a new source port number rather frequently.



I agree that it might be a good idea to grease.



OTOH I do not think that gratuitous migration would be a good solution due to performance issues. We would be required to start from INITCWND every time the client switches to a new address. The fact that we cannot run two paths simultaneously in QUIC v1 makes the performance drawback big.



Rather, I'd prefer making handshake packets indistinguishable from short header packets. In essence, you move the flags of the long header inside the AEAD-protected area. An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails.



> -- Christian Huitema







--

Kazuho Oku

v2.23.0 | Report a Bug | By Email