Re: Getting to consensus on packet number encryption

Christian Huitema <huitema@huitema.net> Wed, 25 April 2018 10:14 UTC

Return-Path: <huitema@huitema.net>
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 8AC0212DA28 for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 03:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 YBTXL8AHjrwS for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 03:14:27 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 BFEB512DA13 for <quic@ietf.org>; Wed, 25 Apr 2018 03:14:20 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fBHRF-0006hF-Hh for quic@ietf.org; Wed, 25 Apr 2018 12:14:19 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fBHQi-0001H8-QP for quic@ietf.org; Wed, 25 Apr 2018 06:14:11 -0400
Received: (qmail 10152 invoked from network); 25 Apr 2018 10:13:35 -0000
Received: from unknown (HELO [10.188.158.213]) (Authenticated-user:_huitema@huitema.net@[37.71.1.100]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 25 Apr 2018 10:13:35 -0000
To: "Deval, Manasi" <manasi.deval@intel.com>, Mark Nottingham <mnot@mnot.net>
Cc: "quic@ietf.org" <quic@ietf.org>
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>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Message-ID: <fc57394f-9516-04c0-0846-6d159b14bc9e@huitema.net>
Date: Wed, 25 Apr 2018 11:13:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Getting to consensus on packet number encryption
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iZANeazKMHMYiXw7z+O/ZF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViALFR1wY4PPlU0jmvzkP1M87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXDzxM5P50wvQiu34cU//edF8FcHzzV3acxBudgYcInb7AMjIAzNNWm 1795oJZLpm6Z4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZuVGBtJ1DsK23UcLYdhI56FwBl1z1+w2zS/h3e6UiVReBILpm2AGusrXQ l3ZFE2I5CpkoeQQIGo2uHp2w1o0OHmeqA47D/juB1cx4exzYk7zESTfxsnn+QWY3vu7vIpAn647l NwN4qOsSZg+fYhVZG7jR1X6ZfhgbqJ49KX9lIV7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TMp30EysYr_mFmKbCyDtVA2OrO4>
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 10:14:29 -0000

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