IETF Logo Mail Archive

Re: Getting to consensus on packet number encryption

Kazuho Oku <kazuhooku@gmail.com> Thu, 05 April 2018 07:56 UTC

Return-Path: <kazuhooku@gmail.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 214861200F1 for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 00:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NlWAyU2q3v9f for <quic@ietfa.amsl.com>; Thu, 5 Apr 2018 00:56:40 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CAD120725 for <quic@ietf.org>; Thu, 5 Apr 2018 00:56:40 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id v13so29495343iob.6 for <quic@ietf.org>; Thu, 05 Apr 2018 00:56:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77wDua7EjMqyaj3I0eZgZmOkkRNS8AxzMxfITbrX+Ww=; b=C7SkJZaDu9NDZy7kLoO0WPXZM7Fjqb1mm6eKhLacmNp6ALxYiF9gc/DkmhM8TQAmip uxhATnsBA0yY8YTGLV8bi9Ai+/kPCnU6bWRyQm/PWrt0g2Y8bcpqDXbDEYioCdxxeViw 6/0fiDUydPUWv02BhbvHc28UCH9kzQxysjVS3GHXKlQHUD10PNhABdmj3TsEXUWkbA8q U8Ua9Zr9tyq1idliVVdUZheUaip6zuwXNK+jzD0uRTfczS/l6SIkyYQD4Z2fd9F0kPND kqsgN7yVgyvCpc2hN6lbIdjDK7zhn5PBKYKjtM25apFOMZXuTISMgYCvZtwIu9OXs9kO 31rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=77wDua7EjMqyaj3I0eZgZmOkkRNS8AxzMxfITbrX+Ww=; b=iD70qNRV0OBjsnijK0WIYrpcnFslp3qrMncX/jS2d+A+oLq1BajH36kaAoammXckru DBn7TjSQzuRRmzix/kcgLiVQ5ES1gf9rcsHYZHcsz9ROcGoW5nfrMMyxGskJMAeP/8C1 5yVO77YL8aKENxL7MGRA+LbhbmhRqcG2t0zNprf+9DY7eefQrXBsFlP5SvlL/E4WGHWW 1VNp1UiZ6a9lC2YSfwS+HrF2nlqtvJGVSBr7vYRjaHEr6fNznARGM0DZbyufuHldEmE/ yevm4OkiBGqNvS8mEn0O5JGmcACpran4a+U1hrjTSi9pjs+gaC9hyesDiKkt0skxwgbN w/iw==
X-Gm-Message-State: ALQs6tCI4lnLHcjtnOKSQWg1b41PwnFaCWGVp8BtnxUJATFMynf+W0Bu joa/ss4HEQY/BJUm1YyvaxaN6EV6oiU=
X-Google-Smtp-Source: AIpwx4/kD8DvdHVM4duo3+rHf57iMWnn6Ch61CdEIY6aNrimx0HqkCM7olyYb2YrVYchLP7FHXZTug==
X-Received: by 10.107.169.81 with SMTP id s78mr18716618ioe.83.1522914999688; Thu, 05 Apr 2018 00:56:39 -0700 (PDT)
Received: from [100.98.202.194] (sp1-72-3-166.msc.spmode.ne.jp. [1.72.3.166]) by smtp.gmail.com with ESMTPSA id w80-v6sm3646817ita.16.2018.04.05.00.56.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 00:56:38 -0700 (PDT)
From: Kazuho Oku <kazuhooku@gmail.com>
X-Google-Original-From: Kazuho Oku <KAZUHOOKU@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-32F7D8EF-8F53-4441-864C-68DC8D6094D0"
Mime-Version: 1.0 (1.0)
Subject: Re: Getting to consensus on packet number encryption
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <CAN1APde75DdXCoK=o92RZ7rva_FdaXkG2_g6opqbhrnigEcKgA@mail.gmail.com>
Date: Thu, 05 Apr 2018 16:56:36 +0900
Cc: Praveen Balasubramanian <pravb@microsoft.com>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Transfer-Encoding: 7bit
Message-Id: <022A1A49-1E9B-4428-8EAE-4C16843715AA@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>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mVteHQsPrABIu39vETNa-uW8Ki0>
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 07:56:43 -0000

2018/04/05 15:00、Mikkel Fahnøe Jørgensen <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.


> How does WebRTC work in this context?
> 
> 
>> On 5 April 2018 at 01.42.23, Praveen Balasubramanian (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.

v2.23.0 | Report a Bug | By Email