IETF Logo Mail Archive

Re: Getting to consensus on packet number encryption

Ian Swett <ianswett@google.com> Wed, 25 April 2018 19:57 UTC

Return-Path: <ianswett@google.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 D8416129C6E for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 12:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 S1vb-_SOfeGj for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 7A18612702E for <quic@ietf.org>; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id q74-v6so8667977ybg.6 for <quic@ietf.org>; Wed, 25 Apr 2018 12:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5BkfTKIRIDA9kuGZtgqFZrkT2SoGCHIZJySq8w2YDQs=; b=pvDYNm1NxdSKf/R531/T2hy9tySBUC8O+9sZWscf8lhktQDSu2lgK6ZdBzqUDlc37v rD0lgJiB6oW3YRwjupcCPYo1faX1ztRvBKhIVfR2kGwwuEqxQSrXVcuE2boaD11KV/DJ I+3EfLnbhokdpxVlu0IKnFPQ5A7DtAe84UKix89MvwTuOS8rVhHpOB6ds4NP9cd2TR+y j+VsbRsJFfngHH8oSCl+ZXkAE6vLczCjoyXOIAvGdhdAzjJpTviD+Gv2EvaAhp1eH9LD k/251cDxLOLLjASq59Q2okeR1CDGPw5UjfsBb/9KDFHpzgIJLBZfrPxzl4ztQZw20gEZ 29rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5BkfTKIRIDA9kuGZtgqFZrkT2SoGCHIZJySq8w2YDQs=; b=s19MEp9hr1iXdnZS+Y4+e9RXz06T5m+9UafmbaRE+s0iV0NA9C8xQqDAsP2D6GJLof BdZ+oTy2AKQJqk/4EV2E/dslO+Deiu7smfCzi2pV3yyafVbhNfArDoS+7MK4WnT958lE J1qL9lk6iQTmjtCNR78R3szJqWwCwdYXKqcXvClHqPkhwgQHvwkomtcJBYieYiKp+ceY 0cVkNSW0kW8YcRXDrF+sXZgmmtje9VegZGaedd6dVAGSaVYEOOdU7DHjcTmRsdobnQSk QbqneSoQEkwMNpKA0Hf4V4lDXf+ftYTYclGLpbSFoqwaghk/+VkMJ9MUUjoLv47L63i1 MUuw==
X-Gm-Message-State: ALQs6tA4GfG8HllaeHtpfi01bUIqwTjYRVzY/kBIic7a0QXcGNNON5d7 7DmmlpPvGsmxUS1Sn+4ngGzDzig9d81Oc0ohabpNmA==
X-Google-Smtp-Source: AIpwx4+xFvgoHxqrr9Je4itmZ6WxMV48h3lVJlAhUjbai565VN9f9D92YqvJv9lt9Xi8+D4lI5t2sMo6YC2Y55OfDGc=
X-Received: by 2002:a25:386:: with SMTP id 128-v6mr16723573ybd.241.1524686228572; Wed, 25 Apr 2018 12:57:08 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <SN1PR08MB1854FD2461597D81BEE31ED6DA8F0@SN1PR08MB1854.namprd08.prod.outlook.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 25 Apr 2018 19:56:57 +0000
Message-ID: <CAKcm_gMRPXgCoZ958Oj4_Pnkvmc9a7PgNVS0iae0hCW7bLKqng@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
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>
Content-Type: multipart/alternative; boundary="0000000000000cd473056ab1ad97"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QAfNYhU8UwtKARceUleTJ5kwlyc>
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: Wed, 25 Apr 2018 19:57:12 -0000

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
>
>

v2.23.0 | Report a Bug | By Email