Re: Getting to consensus on packet number encryption

Roberto Peon <fenix@fb.com> Mon, 30 April 2018 20:24 UTC

Return-Path: <prvs=8658453da1=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 0B0BF127775 for <quic@ietfa.amsl.com>; Mon, 30 Apr 2018 13:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=BXSlgeZh; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ABXOvK0c
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 dX1S2x79i4A8 for <quic@ietfa.amsl.com>; Mon, 30 Apr 2018 13:24:50 -0700 (PDT)
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 E2950127735 for <quic@ietf.org>; Mon, 30 Apr 2018 13:24:50 -0700 (PDT)
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 w3UKO2D3018774; Mon, 30 Apr 2018 13:24:40 -0700
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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=0y96ojM4AedxQx3SVLeXCkDH2ZCFjuITN+T7WvS8LZ0=; b=BXSlgeZhxLi3/ltPg2N+RZ70AbMSfu9nj7av6EWItYgOn3mJT413tldU7Xt4JU543lAz CxVNbRzToerG2km+Nqk3tgrf9cZcvTBzL5yL2f86j3gaqlrNIZ/yK1xb6xN6Bsv60LcW NLAeU3RWd9P6NNabouVz1u01T2Mxfc14D98=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hp9ty01rm-15 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Apr 2018 13:24:40 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 30 Apr 2018 16:23:52 -0400
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=0y96ojM4AedxQx3SVLeXCkDH2ZCFjuITN+T7WvS8LZ0=; b=ABXOvK0cBwlK643CXTlOElTy38Cp+tGiRLmkhxq94tL4n0lp94qozuTjdMRznO9xXRqolp4XSxlUaJgsf/9vsQkjEx753taHGaI/fjlRL7WjyJFOZT8kQZWI+TzVsURvx2E9ygpDkf8Z9HWRPTmSmulF+pJdqmeW93etwkigkXg=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0150.namprd15.prod.outlook.com (10.163.64.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Mon, 30 Apr 2018 20:23:49 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e%14]) with mapi id 15.20.0696.019; Mon, 30 Apr 2018 20:23:49 +0000
From: Roberto Peon <fenix@fb.com>
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, Kazuho Oku <kazuhooku@gmail.com>, Erik Kline <ek@google.com>
CC: Mark Nottingham <mnot@mnot.net>, Christian Huitema <huitema@huitema.net>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Mike Bishop <mbishop@evequefou.be>, IETF QUIC WG <quic@ietf.org>, "Deval, Manasi" <manasi.deval@intel.com>
Subject: Re: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GjyGQaKf4GI0anNhXTngANsKPwZ0sAgAC4ugCAAARcAIAAG5CAgAAFCACAAACJgIAAEVkAgACR+ICAAVFHAIALXUEAgAVKTpWAAJn+AIABxdSAgACOHICAB/EyAIACo7YAgACiL4CAAADQgIAAIs8AgAAm/YCAABExgIAABpIAgAAK6ACAAPIgAIAGDzkA
Date: Mon, 30 Apr 2018 20:23:49 +0000
Message-ID: <F5B93B5C-9D08-490E-AB6F-61E45C7EB9E1@fb.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.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> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> <B0F49097-F77A-4831-B68B-4266AA880A86@tik.ee.ethz.ch> <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch> <BY2PR15MB0775B4ACF7DB9124E89016F0CDB00@BY2PR15MB0775.namprd15.prod.outlook.com> <c8e60ba4-d6be-c4fc-5bac-d569a28fb4e8@huitema.net> <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net> <ae7a63fe-0a32-893f-aa6b-e8d97b8ba87a@huitema.net> <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com> <fc57394f-9516-04c0-0846-6d159b14bc9e@huitema.net> <SN1PR08MB1854FD2461597D81BEE31ED6DA8F0@SN1PR08MB1854.namprd08.prod.outlook.com> <CAKcm_gMRPXgCoZ958Oj4_Pnkvmc9a7PgNVS0iae0hCW7bLKqng@mail.gmail.com> <SN1PR08MB18545D0554DED1F83862EBFBDA8F0@SN1PR08MB1854.namprd08.prod.outlook.com> <CAKcm_gNMTQg-pV8vTXkMCTh48QPZ_ujyFSEKRYf+WurUFytaWw@mail.gmail.com> <CANatvzwCYrOZULG3iVmDFp97nr=M5=Gufo8TZjOGQVFUpsn0bQ@mail.gmail.com> <CAAedzxqDcPXJUE83KVnDiU23PvqDcTCrc6rRMw09FexjJA-Y6Q@mail.gmail.com> <CANatvzwjYE6EdvFtOXJMVQnutbVQ4YY+=XsQFzKwHzqWzZ4U+w@mail.gmail.com> <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: [199.201.64.131]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0150; 7:BSoJ7nn+mGo78Dct0EE4weVufDsSEg9DViUTgo3FP+uPh4sHpb/RDsYkAp80N7nUEq/c5g3X5vichC2v3CLJiSx/6/RTptXGlnvQvCQPa9aYrDTUpQCLWg8NtJoZGw9v0ylzkog4B/4BR64DV5Jk2X8tZygUnZ40ETZHAMUiWdo48MOg0sPRncDW5tL11EDAz99O9e31ilYkDgoH0/pLo+LLe9RIEitbPX2U6ORAcrBmpJFYBIW+E05hijnWv6XI; 20:dcylYLWJ7590FNtut5HSLSAH6u1gZKlKafAOxr+BfYfu48h2ksMBSL1nYjvGVSzDoTKol4XDtn061kU2J6Bl1Fm/4a4yPYQFQggt3+98g5b0gvhA40olbAhxl4MYzOcKMhdeU09PbqTeVV1AGmj+hn2Rl5lfx/HBSWWAblvV37Q=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0150;
x-ms-traffictypediagnostic: BY2PR15MB0150:
x-microsoft-antispam-prvs: <BY2PR15MB015051FE1C766C282475FFA5CD820@BY2PR15MB0150.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(228905959029699);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(11241501184)(944501410)(52105095)(10201501046)(3002001)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0150; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0150;
x-forefront-prvs: 0658BAF71F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(366004)(396003)(346002)(39860400002)(199004)(13464003)(189003)(51914003)(377424004)(51444003)(53546011)(478600001)(105586002)(102836004)(82746002)(6506007)(110136005)(14454004)(8676002)(8936002)(97736004)(106356001)(59450400001)(6306002)(39060400002)(66066001)(6512007)(2900100001)(4326008)(486006)(81166006)(316002)(81156014)(99286004)(25786009)(5660300001)(6246003)(53936002)(76176011)(36756003)(186003)(33656002)(11346002)(3846002)(2906002)(476003)(54906003)(26005)(86362001)(305945005)(58126008)(7736002)(3660700001)(575784001)(6436002)(68736007)(2616005)(229853002)(3280700002)(83716003)(6486002)(446003)(93886005)(6116002)(5250100002)(966005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0150; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jxw/ZNzRZWkBpCI2MksBzdM8HPz9tj62aNC7q9NqKvFTCU0HR6JkrdmOW+acPs9k9Z2U6edRg0JhlTadD33KjDMqtCEjXVLukIH/WCCDS6Jdz0CghBiPp8LQxfD1Fmi6VnQlirlZHOTQdXImpUtBbnOuhksw6JtqU5C3nGtTr0Moa+y31AE91ZTWrf7jxWtq
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D01AAB9F5B779F4BA11799FB574AEF5C@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 0ced2bcf-3e22-433c-ab43-08d5aed848a1
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ced2bcf-3e22-433c-ab43-08d5aed848a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 20:23:49.6110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0150
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-30_08:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hKijRqFxv4OeMU_mkYKnw9p1etg>
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: Mon, 30 Apr 2018 20:24:53 -0000

This kind of 'obvious' "breakage" is less easy to game (it is unsubtle), and thus preferable.
-=R

On 4/26/18, 9:52 AM, "QUIC on behalf of Lubashev, Igor" <quic-bounces@ietf.org on behalf of ilubashe=40akamai.com@dmarc.ietf.org> wrote:

    > if some middleboxes decide to pass QUIC without PNE but block QUIC with PNE, we might be incentivized to use QUIC without PNE.
    
    
    
    If a middlebox really dislikes PNE, it can just block QUIC altogether, forcing a TCP fallback.  Is TCP better than QUIC-without-PNE from any POV in that situation?  (And if so, this should be the recommendation to QUIC stacks with negotiable PNE -- fallback to TCP, if path is blocking PNE.)
    
    
    
    - Igor
    
    
    
    -----Original Message-----
    
    From: Kazuho Oku [mailto:kazuhooku@gmail.com] 
    
    Sent: Wednesday, April 25, 2018 10:25 PM
    
    To: Erik Kline <ek@google.com>
    
    Cc: Mark Nottingham <mnot@mnot.net>; Mike Bishop <mbishop@evequefou.be>; Ian Swett <ianswett=40google.com@dmarc.ietf.org>; Christian Huitema <huitema@huitema.net>; IETF QUIC WG <quic@ietf.org>; Deval, Manasi <manasi.deval@intel.com>
    
    Subject: Re: Getting to consensus on packet number encryption
    
    
    
    2018-04-26 10:46 GMT+09:00 Erik Kline <ek@google.com>:
    
    > Couldn't a middlebox have a policy where it permits QUIC sessions w/o 
    
    > PNE but blocks sessions with PNE?  Then implementations would be 
    
    > forced to choose how adapt: break altogether, maybe try TCP, or 
    
    > disable PNE and carry on.
    
    
    
    There are two ways of negotiating the use (or non-use) of PNE. One is use Transport Parameters and the other is to use a different QUIC version.
    
    
    
    Use of Transport Parameters is secure because it is part of the TLS handshake. Version negotiation has it's own protection against downgrade (or upgrade) attacks (see https://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_base-2Ddrafts_draft-2Dietf-2Dquic-2Dtransport.html-23rfc.section.6.4.4&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=zC1VGmf3GQmWVe467ufLNulxuNhUTlKEQwOA80nBUUY&s=fvtchwAG-YxJcR8wUAezTwCSN6X8EH8E-7MlSo1p1nM&e=).
    
    
    
    So I would assume that a middlebox trying to intervene in the negotiation of PNE use can be detected.
    
    
    
    That said, I do see your point that if some middleboxes decide to pass QUIC without PNE but block QUIC with PNE, we might be incentivized to use QUIC without PNE. In such case, we might end up having privacy leaks & ossification.
    
    
    
    I think that is a good argument for always having PNE turned on.
    
    
    
    >
    
    > On 26 April 2018 at 01:22, Kazuho Oku <kazuhooku@gmail.com> wrote:
    
    >> 2018-04-26 9:21 GMT+09:00 Ian Swett <ianswett=40google.com@dmarc.ietf.org>:
    
    >>> It has been, and I'm personally supportive of it, because I believe 
    
    >>> it'll be useful for datacenter QUIC use cases.
    
    >>>
    
    >>> But the WG has to decide:
    
    >>>  1) Is it allowable to disable PNE?
    
    >>
    
    >> There are two concerns that PNE is trying to address: ossification and privacy.
    
    >>
    
    >> I won't mind if some portion of QUIC-like traffic has no mechanism to 
    
    >> prevent ossification. This is because we can train the middleboxes to 
    
    >> not ossify the PN field by having PNE in the majority of the traffic 
    
    >> that they will see.
    
    >>
    
    >> OTOH, I would be worried of privacy implications. Once you define a 
    
    >> protocol, it is hard to control how it is going to be used.
    
    >>
    
    >> But with that said, I think we might better wait to see if somebody 
    
    >> still thinks he/she *needs* QUIC without PNE.
    
    >>
    
    >>>  2) What the mechanism is?  ie: Unilateral via TransportParams or 
    
    >>> negotiated via an extension or ?
    
    >>>
    
    >>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop <mbishop@evequefou.be> wrote:
    
    >>>>
    
    >>>> I think that’s been suggested before, though we’d need to sort out 
    
    >>>> the details of what that looks like.  I don’t have a particular design in mind.
    
    >>>>
    
    >>>>
    
    >>>>
    
    >>>> From: Ian Swett [mailto:ianswett@google.com]
    
    >>>> Sent: Wednesday, April 25, 2018 12:57 PM
    
    >>>> To: Mike Bishop <mbishop@evequefou.be>
    
    >>>> Cc: Christian Huitema <huitema@huitema.net>; Deval, Manasi 
    
    >>>> <manasi.deval@intel.com>; Mark Nottingham <mnot@mnot.net>; IETF 
    
    >>>> QUIC WG <quic@ietf.org>
    
    >>>> Subject: Re: Getting to consensus on packet number encryption
    
    >>>>
    
    >>>>
    
    >>>>
    
    >>>> Hi Mike,
    
    >>>>
    
    >>>>
    
    >>>>
    
    >>>> To clarify, are you suggesting adding a way to disable packet 
    
    >>>> number encryption via negotiation in the v1 spec as well as 
    
    >>>> adopting #1079?  Or would the choice of whether PNE is to be used 
    
    >>>> unilateral, such as a transport param?
    
    >>>>
    
    >>>>
    
    >>>>
    
    >>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop <mbishop@evequefou.be> wrote:
    
    >>>>
    
    >>>> Yes -- it seems that the biggest objection to #1079 was the 
    
    >>>> difficulty in hardware implementation.  If we're hearing that 
    
    >>>> hardware implementation is feasible at a reasonable cost, then I think we might have a winner.
    
    >>>>
    
    >>>> The CPU cost for a software implementation is still worth 
    
    >>>> considering, and an option to not encrypt is probably reasonable to 
    
    >>>> limit that burden for implementations / use cases that don't care.
    
    >>>>
    
    >>>> -----Original Message-----
    
    >>>> From: QUIC <quic-bounces@ietf.org> On Behalf Of Christian Huitema
    
    >>>> Sent: Wednesday, April 25, 2018 3:14 AM
    
    >>>> To: Deval, Manasi <manasi.deval@intel.com>; Mark Nottingham 
    
    >>>> <mnot@mnot.net>
    
    >>>> Cc: quic@ietf.org
    
    >>>> Subject: Re: Getting to consensus on packet number encryption
    
    >>>>
    
    >>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
    
    >>>>
    
    >>>> > I had brought up the issue with PNE several weeks ago as a 
    
    >>>> > barrier to hardware offload. After further review, it looks like 
    
    >>>> > a hardware offload can implement the PNE at a small cost.
    
    >>>> >
    
    >>>> > The implementation can modify current HW crypto accelerators to 
    
    >>>> > support encrypting a buffer in the first pass and then encrypting 
    
    >>>> > packet number in the 2nd pass as already discussed on this 
    
    >>>> > thread. The exact requirement (header checksum, packet length 
    
    >>>> > encoding) is still in flux so there may be some small variations 
    
    >>>> > depending on the accelerator and final algorithm chosen for PNE. 
    
    >>>> > Future offload designs can do more to further reduce the overhead.
    
    >>>>
    
    >>>> Thanks for the information, Manasi. I have modified the wiki page 
    
    >>>> describing the PNE issues and alternatives to reflect this new data:
    
    >>>>
    
    >>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives..
    
    >>>> With that new information, it appears that PR #1079 is superior to 
    
    >>>> every other alternative.
    
    >>>>
    
    >>>> -- Christian Huitema
    
    >>
    
    >>
    
    >>
    
    >> --
    
    >> Kazuho Oku
    
    >>
    
    
    
    
    
    
    
    --
    
    Kazuho Oku