IETF Logo Mail Archive

Re: Getting to consensus on packet number encryption

"Philipp S. Tiesel" <phils@in-panik.de> Thu, 05 April 2018 09:58 UTC

Return-Path: <phils@in-panik.de>
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 AF6CC126BF3 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 02:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 V8z2rg3OmMKh for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 02:58:42 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 213AD124205 for <quic@ietf.org>; Thu, 5 Apr 2018 02:58:32 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w359vSQS005768 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 11:57:28 +0200
Received: from teststation.net.t-labs.tu-berlin.de ([2001:638:809:ff1f::8295:dc3a]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <phils@in-panik.de>) id 1f41dO-0006WY-Gn; Thu, 05 Apr 2018 11:56:46 +0200
From: "Philipp S. Tiesel" <phils@in-panik.de>
Message-Id: <BD627982-AA4F-4A76-BE95-78B62C1393E7@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9DDAD3B0-42BD-4116-8244-423D0B33D64A"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Getting to consensus on packet number encryption
Date: Thu, 05 Apr 2018 11:57:27 +0200
In-Reply-To: <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Praveen Balasubramanian <pravb@microsoft.com>, IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Lars Eggert <lars@eggert.org>
To: Kazuho Oku <kazuhooku@gmail.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <F9FCC213-62B9-437C-ADF9-1277E6090317@gmail.com> <CABcZeBM3PfPkqVxPMcWM-Noyk=M2eCFWZw2Eq-XytbHM=0T9Uw@mail.gmail.com> <CAN1APdfjuvd1eBWCYedsbpi1mx9_+Xa6VvZ3aq_Bhhc+HN67ug@mail.gmail.com> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <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> <CAN1APde75DdXCoK=o92RZ7rva_FdaXkG2_g6opqbhrnigEcKgA@mail.gmail.com> <022A1A49-1E9B-4428-8EAE-4C16843715AA@gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eGRha3jFSkyd7CDpHYN7SsOqCUM>
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 09:58:44 -0000


> On 5. Apr 2018, at 09:56, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> 2018/04/05 15:00、Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com <mailto:mikkelfj@gmail.com>>のメール:
> 
>> There is also the concern raised by some that packet reordering in transit could happen without PN - this is always an issue - but is it worth the cost, and is it still a real concern for a protocol that was not designed to be strictly ordered?
> 
> I agree that reordering by middleboxes *might not* happen. But I would also argue that we should encrypt the PN if we think reordering *might* happen.
> 
> If we encrypt PN now, we will have the chance to revisit the design in the future versions of QUIC. But if we ship without PNE and then find out middleboxes start using the PN under the assumption that they are sent in-order, we would forever be forced to stick to them sent in-order, in cleartext. 
> 
> Ossification closes the door to future modifications.

For the case of the PN, I also see this problem, but (inspired by Brian), 
I started thinking of this from a different perspective:

What if we think of the "clear PN" as a path signal, which is coincidentally used as PN in the transport in v1.
For me, the consequences seem the following:
 - It instantly becomes somewhat of an invariant, for which we can clearly define
   behaviour (monotonically increasing, jumps infrequent, …) 
 - Need to design the "clear PN” for space efficiency – use a variable length
   integer that can reduce to one byte if we have a "transport PN" in the encrypted
   part in v2

Maybe a “faster” way forward without needing to feel ossified.

> 
> 
>> How does WebRTC work in this context?
>> 
>> 
>> On 5 April 2018 at 01.42.23, Praveen Balasubramanian (pravb@microsoft.com <mailto:pravb@microsoft.com>) wrote:
>> 
>>> What is the privacy issue if you are not doing migration? Migration + PNE (or multiple PN spaces) should go hand in hand.

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

v2.23.0 | Report a Bug | By Email