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

Praveen Balasubramanian <pravb@microsoft.com> Thu, 05 April 2018 18:19 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 691E312AF84 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 11:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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=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 9PSWIh1PozBt for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 11:19:26 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0120.outbound.protection.outlook.com [104.47.32.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47203129C6D for <quic@ietf.org>; Thu, 5 Apr 2018 11:19:26 -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=1W8g4r2tTiZki7j+KI6RWstYibwM6cMo8YYtEzC28HM=; b=Tnb0TW7skqAri7JjM6+YhNmtuGqCIAw+9csXReu4pesKym1Xr334E4Yl8e2yGCh9+tR3mur8rO/DP4mxoTtsJdA85KdCxTRimqrzsX/sCu3UGJWbCtpe4GgSvh1vfWbQXUINMyQtugOXPSD+ktNOovK0297P1wne3nRC5ErwTwE=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.1; Thu, 5 Apr 2018 18:19:23 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::de:ba33:4748:51da%6]) with mapi id 15.20.0675.003; Thu, 5 Apr 2018 18:19:23 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Kazuho Oku <kazuhooku@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>
CC: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, huitema <huitema@huitema.net>, Mike Bishop <mbishop@evequefou.be>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, 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: AQHTzPOfhJMCgvyw60+hsX7hCsq0T6PyVBsAgAACsgCAABOkAIAAAk8AgAABDICAAAfeAIAAAtaAgAACq3A=
Date: Thu, 05 Apr 2018 18:19:22 +0000
Message-ID: <CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0@CY4PR21MB0630.namprd21.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> <SN1PR08MB1854010FD61AC17D19E497FDDABB0@SN1PR08MB1854.namprd08.prod.outlook.com> <CAN1APddJ7b+7Ydtw7i5c3XBHiC3mz9FmJEM-kZ0=Y8DvmpQ0eg@mail.gmail.com> <a02101a18f16419f81233058a1a6de15@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzyEWb1esUcPL=pP6eDmyB7cmfuUOn6vGMTui3Jr+Z-oQQ@mail.gmail.com>
In-Reply-To: <CANatvzyEWb1esUcPL=pP6eDmyB7cmfuUOn6vGMTui3Jr+Z-oQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:a::712]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0856; 7:O4CDZHK1AprjHOvFt+JcBYR0LoiErigUIjm+aTZKbGkNk0m3ycDphPcv74uItMPmAfLJxJriF/w47S+UtJBryEAYKNYZcj/QiKkOu7drkLsO1Jtm1oq+xm6toB/ngS7rZq+sK5KhHCPQwkMX1n+r+vLSWEMwEl7F7ueGTCwzGo+symxP+SeybLQoyQFDCYSfMmFMEoEhv1k1qC01ubu7vam4fXTTWFc2mmCphDAnTsMW58gVL08BoRteJg6chAtG; 20:/7SEgdmdm+jHctUtqvWkKTpNS/sJMfgjTpGUrgAikXCLaRzDNX5meseS87JBTR3PLebaF+ORXItW/DCt/I/JVoHLq8D4t+kUPzPqxYwTwYw4MDKHQ2jrlKfiAwXNyN8+Lw4zix1jEKTPWpS5X5Jlg3btsY66TtD8Bz53bRdgXRM=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7cd69645-838d-4fe2-e221-08d59b21c1d8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0856;
x-ms-traffictypediagnostic: CY4PR21MB0856:
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: <CY4PR21MB08561DE74774B8EBB1D86C8DB6BB0@CY4PR21MB0856.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(100405760836317)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(10201501046)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0856;
x-forefront-prvs: 06339BAE63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(376002)(396003)(346002)(199004)(189003)(377424004)(8990500004)(6506007)(2900100001)(110136005)(54906003)(46003)(476003)(93886005)(5660300001)(14454004)(11346002)(2906002)(5250100002)(105586002)(7736002)(86362001)(478600001)(74316002)(102836004)(53546011)(486006)(19609705001)(186003)(86612001)(68736007)(8676002)(97736004)(81156014)(22452003)(76176011)(39060400002)(3280700002)(8936002)(446003)(25786009)(81166006)(10090500001)(6246003)(561944003)(106356001)(55016002)(54896002)(790700001)(3660700001)(6306002)(6116002)(53936002)(6436002)(316002)(9686003)(236005)(10290500003)(229853002)(99286004)(33656002)(7696005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: X3aJN7jQtL9jZkaXb+iwsMtMVhE2NJ1jPIi27GTEUJ4gqPstcGpbZ4zk/fABxVf8Z+wtaviFyDhYql33uwcZd8lfIvXR/8C9etDFE569y0yiYB+V3FqZ38Rc7RSZtbXHrAJRW/xGIoSLXK+4EmM3o8uhvZ8NO6/tQa5F05L6HQaQfBKfT60jPlzREm9Qblhhs+8I2k/ArdBdAA6TwehguIgBjCN6b14k3NYzDskG6sG41iOmL/axCiRMR14+EYhEz7mDUflkF8/DYzZ2/B+CI1I3+YB9C/0ewqqppV1vLJutvRKPwkndCLcYGqexCbkQzAb9UYtwHEFJzLPX3bmSXp9czrA0Uqwd1XmwIG2LpjWd2NChOf49fr/ckc1Zp5TjLT6DotOLEB6d9k0/qS0Q2K+Y3TPrN3ptf0febdEyGdk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0630BF7EC130BD8987C8CE11B6BB0CY4PR21MB0630namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cd69645-838d-4fe2-e221-08d59b21c1d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 18:19:22.9334 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7zvrZCAZ_kjUK7ov87D3DzXnJzg>
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 18:19:29 -0000

IMO we should not have a design that forces load balancers to decrypt.

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Kazuho Oku
Sent: Thursday, April 5, 2018 11:09 AM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; huitema <huitema@huitema.net>; Mike Bishop <mbishop@evequefou.be>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <quic@ietf.org>; Frederick Kautz <fkautz@alumni.cmu.edu>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)



2018-04-06 2:59 GMT+09:00 Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>:

  *   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.
This change would wreck stateless load balancers that rely on being able to distinguish CI packets (and route them based on IPs) from other packets (and route them based on CID).

It would not, *if* the stateless load balancer can AES-decrypt the packet (using the key derived from the packet header) to see if the packet is in fact a initial packet. Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer.

I agree that it would be a no-deal for stateless load balancers that are incapable of doing such things.


- Igor

From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>; Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>>
Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch<mailto:mirja..kuehlewind@tik.ee.ethz.ch>>; Frederick Kautz <fkautz@alumni.cmu.edu<mailto:fkautz@alumni.cmu.edu>>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

Hi


On 5 April 2018 at 19.27.24, Mike Bishop (mbishop@evequefou.be<mailto:mbishop@evequefou.be>) wrote:

 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.

I can see hiding things may be a good thing, but having to trial decrypt all unknown packets as potentially creating a huge load, unless you combine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average to reject random packet content.

It won’t solve all DDoS, but it will help. Forcing trial decryption fo the full packet makes me a bit anxious.



Mikkel





--
Kazuho Oku