Re: Packet number encryption

"Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com> Fri, 02 February 2018 15:32 UTC

Return-Path: <thomas.fossati@nokia.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 3573A12783A for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 07:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 03g8EXMtWx9W for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 07:32:55 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B541267BB for <quic@ietf.org>; Fri, 2 Feb 2018 07:32:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eUk7uKhXvBFdLi9/ZsASzMv2gejVPMQkJVj56eoJWtY=; b=iLB5THBK2kPB6g2Dj33yXncAaS6pzSbwAHAHkns6GqE+wkH3B4IACyLnjvuyQm2d5Q4GjRaWgSUxIfk0H6BeniLfwYi672nB2FUTqevx/O1PUPZt2dAw4U5xql2yLOmWr4Re+LvIOwJLPbWJQu4hTRlGad50dAdAlWPHIxrHopE=
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0700.eurprd07.prod.outlook.com (10.160.51.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 15:32:50 +0000
Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.012; Fri, 2 Feb 2018 15:32:49 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
To: "Eggert, Lars" <lars@netapp.com>, Gorry Fairhust <gorry@erg.abdn.ac.uk>
CC: Eric Rescorla <ekr@rtfm.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Christian Huitema <huitema@huitema.net>, Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
Subject: Re: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW31fyIlPY67nUiLThH52NyNBqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQA=
Date: Fri, 02 Feb 2018 15:32:49 +0000
Message-ID: <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com>
In-Reply-To: <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.9.0.180116
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com;
x-originating-ip: [88.111.115.17]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR07MB0700; 7:NZy6SmE/MhZ4Bc3v98xz3RR3Ur74r0wVwTtVuUQ0xukj1QmUUASVflIi/Fz1SGoqpW2ayLRFYH79ZwXVs0BlyTIvaG0LFudjKCyf18HuzaiPY39uiZ2r8+czAZEE71XBC+RijKYnqgL69Kce1s1zS8/WAtjf3iJzmmdMfTTA5tPLinPn6sZcX40WucER0k8RaN52ZZYUv02DLRRytQsqr1hyRHWMVh1pbxfAu66erVmfhkFNgKHi1mtpGtUVJip1
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(346002)(39380400002)(377424004)(189003)(11905935001)(199004)(8936002)(102836004)(33656002)(26005)(36756003)(39060400002)(316002)(82746002)(6436002)(6116002)(966005)(6506007)(3480700004)(25786009)(68736007)(76176011)(86362001)(2900100001)(14454004)(54906003)(83716003)(8676002)(106356001)(81166006)(93886005)(83506002)(53546011)(2906002)(81156014)(3846002)(105586002)(6246003)(3660700001)(478600001)(4326008)(58126008)(305945005)(5250100002)(4001150100001)(110136005)(7736002)(186003)(7116003)(2950100002)(99286004)(107886003)(5660300001)(66066001)(229853002)(6306002)(3280700002)(97736004)(6486002)(6512007)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0700; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6b758c97-e0f3-42f5-73a6-08d56a5237c7
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB0700;
x-ms-traffictypediagnostic: DB3PR07MB0700:
x-microsoft-antispam-prvs: <DB3PR07MB0700A6325A24F24763B9939880F90@DB3PR07MB0700.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(130329453890623);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(11241501184)(806099)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0700; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0700;
x-forefront-prvs: 05715BE7FD
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 1o6K0guBuzhdk4/OMZuXfo5QhbeW/clNBthzySLiPHZ4hW7i2SGHhjLLZZDdg885pOY8dOQ90NSliOu0KNgQUROYyLoAp/D8WxQhiHyE1yxWrey2fdRaNs866oXn3pJo
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C72AA80F82DFB6478AB50EA8DA16E89B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b758c97-e0f3-42f5-73a6-08d56a5237c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 15:32:49.6444 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2hF8XqLeRKub0N56n4o6I5Ikht0>
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: Fri, 02 Feb 2018 15:32:57 -0000

On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little.
> 
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higgs
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-equation