RE: Packet number encryption

Mike Bishop <mbishop@evequefou.be> Mon, 05 February 2018 18:59 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 4D9B012D940 for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 10:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 n94DErRGCi2D for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 10:59:13 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551411275AB for <quic@ietf.org>; Mon, 5 Feb 2018 10:59:13 -0800 (PST)
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=rCZvuHLHNVorIiKcQPNcPOldDzc3LfRWwDhRFfNUeOY=; b=JgX/wm/7W2f6ws4JNYWRifrpDZ3GvsPvxSY2F/S4No27SxPGUL6RRnE03kpmv28ltFGFE50QgJhbytHZ3vq/No1NFwAKPLozyr7qN8LyzvtwkcM4TLfuNUIBOJcPWY9MZRUSSxy6bmllqUis3KSBcLfjVCQJ1LzGWbFAvkLbWmw=
Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB3405.namprd08.prod.outlook.com (10.164.203.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 18:59:09 +0000
Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 18:59:09 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: "Roni Even (A)" <roni.even@huawei.com>, "quic@ietf.org" <quic@ietf.org>
CC: Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Packet number encryption
Thread-Topic: Packet number encryption
Thread-Index: AQHTmW33YzpoOLX0UU2dbBSG8l3vaKOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAC0PSAgAENaICAAA6uAIAAS1MQ
Date: Mon, 05 Feb 2018 18:59:09 +0000
Message-ID: <MWHPR08MB2432C99878A3796A73F60C24DAFE0@MWHPR08MB2432.namprd08.prod.outlook.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> <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com> <CAGD1bZab0GaZFsHwC+nw3AxxC4VusxMJ6oDanzk3dSDdWKAXdw@mail.gmail.com> <EEB6849E-B358-49A3-A85D-F3F4A9C6B576@trammell.ch> <CANatvzzAseF2FxhqNg+6EwqVGioB7v4ez1QNe+KqyAP8-0nS5w@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD861F8E@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD861F8E@DGGEMM506-MBX.china.huawei.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; MWHPR08MB3405; 7:AIr7AaynUDmSYGKz+wbcbhwtEY/GgTz14z5vg1z45DFy8nX6lyUytUVXaYSVbF0XGTv/EBO/Mgxfu1VF19vJa0FlYeaqAIZzSprkx4lBNhN1xlIAWi7iZjYwsxBdH2vCS1BaJY2rifgj/j8hwVMpKQbFtwx2xTzvZ0xiocC/g+RTe6BZFuhfg3C7lrqS9BhHLM9toJ9gyBECCfLmUSNKSqSr1b2P3AVJ4KKDv/SCWXGEB8L146KGyrCFDnoCJfE1
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ebfe5264-7a25-484c-4d1d-08d56cca89f4
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB3405;
x-ms-traffictypediagnostic: MWHPR08MB3405:
x-microsoft-antispam-prvs: <MWHPR08MB34057B1603BA10EEB75563E0DAFE0@MWHPR08MB3405.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(82608151540597)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(130329453890623);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123562045)(2016111802025)(20161123560045)(20161123564045)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB3405; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB3405;
x-forefront-prvs: 0574D4712B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39380400002)(346002)(39830400003)(189003)(199004)(377424004)(13464003)(11905935001)(6116002)(6246003)(39060400002)(53936002)(966005)(55016002)(9686003)(6436002)(14454004)(93886005)(229853002)(8676002)(7116003)(5660300001)(81166006)(81156014)(8936002)(3280700002)(68736007)(3846002)(316002)(3660700001)(2950100002)(6306002)(33656002)(2501003)(7696005)(2906002)(74316002)(3480700004)(102836004)(4001150100001)(106356001)(110136005)(99286004)(66066001)(97736004)(25786009)(26005)(478600001)(86362001)(77096007)(105586002)(59450400001)(2900100001)(6506007)(53546011)(4326008)(186003)(76176011)(7736002)(74482002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3405; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: YzRxrMDqShJjRfEuj5CNUXx/7onZuzaXz6y21NOV4JMtsJ/CG4Oukv44hCJ8DBsQhcYN0BxeBx5CImcM/WfdFA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: ebfe5264-7a25-484c-4d1d-08d56cca89f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 18:59:09.4600 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3405
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mGataiq4nrTgZnYH9clZK04I6e4>
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, 05 Feb 2018 18:59:16 -0000

There are overlapping interests, but they are certainly not the same.  When someone on the network side says "reliable," everyone at the endpoints hears "ossified," because once the network starts relying on a behavior, you can't realistically change it.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Monday, February 5, 2018 6:28 AM
To: quic@ietf.org
Cc: Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Packet number encryption

Hi,

I want to comment on
" There are two parties with different interests. Endpoint developers want something more straightforward to implement and also is safe from ossification. Operators want a tool for diagnosis."

I agree that there are two parties but I hope that we share the same interest which is to have a secure, reliable protocol that also support manageability in actual transport networks.

As for having parallel mechanisms, one of the points about the usability of spin bit was that it not part of the protocol state machine and that makes it less reliable,

Roni

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Kazuho Oku
Sent: Monday, February 05, 2018 3:36 PM
To: Brian Trammell (IETF)
Cc: Gorry Fairhurst; Eric Rescorla; Christian Huitema; Fossati, Thomas (Nokia - GB/Cambridge, UK); Mirja Kühlewind; Eggert, Lars; Jana Iyengar; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

2018-02-05 6:31 GMT+09:00 Brian Trammell (IETF) <ietf@trammell.ch>:
> hi Jana,
>
>> On 3 Feb 2018, at 03:30, Jana Iyengar <jri@google.com> wrote:
>>
>> A few points as I catch up on this thread.
>>
>> First, I'll remind folks that QUIC is an encrypted transport. I say this because the cost of this operation is trivial in the context of encrypting every packet. The cost is borne at the servers and not at middleboxes, so the additional crypto cost is basically trivial.
>
> After having worked my way through the PR again (and essentially rewriting it from the receiver's point of view, which I believe would be useful text to have in the final document, should we end up doing this), I buy this.
>
>> Second, this simplifies and increases robustness of implementation. Avoiding random PN jumps, as Kazuho points out, makes special-casing of code unnecessary. Special code that is exercised occasionally is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.
>
> Agree completely. Packet number jumps are a bad idea, and there seems to be a (not explicitly examined) consensus that attempting to make linkability difficult is worth the effort.
>
>> Third, yes, ossification is a real concern. A simple example: using increasing packet numbers as a signature for detecting QUIC. Even if you argue against this example, there are innovative ways in which ossification will happen. This is based on a true story: We had no idea how GQUIC's flags field could get ossified, the value that was being used commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).
>
> There's an overgeneralization of experience from ossification of single static fields (as in the TLS greasing and GUIC flags cases) to functions over the time series of these fields which has not yet been shown to be valid IMO in the case of integrity-protected wire images -- will expand on this in my next message, replying to Roberto.
>
>> There's a win here in terms of implementation complexity and several implementers have said so.
>
> Compared to packet number jumps, absolutely. Compared to the state two revs of the draft ago, it's a *little* more complex but at least it doesn't add completely new operations at the sender or the receiver.
>
>> There's a win in terms of ossification and our experience says so.
>
> That experience is IMO overgeneralized.
>
>> There's a potential loss of manageability, in being able to detect reordering.
>
> Well, upstream loss and upstream reordering.
>
> As Christian suggested at the start of this thread, if we simultaneously add back a signal that would allow on-path loss and reordering detection, that would make this a usable-information-content-neutral change to the wire image, and everyone could leave the table happy.

+1

There are two parties with different interests. Endpoint developers want something more straightforward to implement and also is safe from ossification. Operators want a tool for diagnosis.

In TCP, both parties have used the same signal for their tasks.

In QUIC, we can split the signal into two, which can be tailored for each use-case.

The split would help the protocol evolve (as fit from endpoint developers' perspective). At the same time, it could also help operators, since the signal they use can become more stable or evolve in a different pace (since the changes to the encrypted part of the protocol will not affect what the operators will see, or vice-versa).

Note also that even in the current unencrypted form, packet numbers of QUIC is not as easy to use compared to TCP (from operators' viewpoint) since the numbers monotonically increase and since ACKs are encrypted.
So there's a chance to make the signal more useful by splitting the signals. Spin bit is a good example.

> The only problem with this is that the most obvious place to put this signal -- the four bits we get back from the short header type field (assuming we add the spin bit) aren't really enough to track the loss and reordering patterns we care about with a naive counter.
>
> There are lots of other options in this space (e.g. decide we care about latency more than reordering, and that we don't care about loss at all, and use a two-bit spin to protect the latency signal from reordering, and so on), but that seems like a third thread we should start.
>
> Cheers,
>
> Brian
>
>> This is the trade-off, and I am still in favor of encrypting packet numbers.
>>
>> On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:
>> 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-m
>> odel-equation
>>
>>
>



--
Kazuho Oku