Re: Packet Number Encryption outside of AEAD

Christian Huitema <huitema@huitema.net> Sat, 28 July 2018 14:41 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 2D9E4130F52 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 07:41:26 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 2TdfjLxDoiz4 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 07:41:23 -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 E3FD7130ECF for <quic@ietf.org>; Sat, 28 Jul 2018 07:41:22 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fjQOh-0005Bg-8d for quic@ietf.org; Sat, 28 Jul 2018 16:41:19 +0200
Received: from [10.5.2.16] (helo=xmail06.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 1fjQOc-0003Mz-CM for quic@ietf.org; Sat, 28 Jul 2018 10:40:42 -0400
Received: (qmail 1084 invoked from network); 28 Jul 2018 14:40:31 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.107]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <manasi.deval@intel.com>; 28 Jul 2018 14:40:30 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-AA0DC0A4-40A8-481D-82F8-8B2A397E48AD
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <CAN1APddn19A1xO74wwSDte5qjjtJC7o2gGi53JW22jcTm89iJQ@mail.gmail.com>
Date: Sat, 28 Jul 2018 07:40:28 -0700
Cc: "Deval, Manasi" <manasi.deval@intel.com>, Kazuho Oku <kazuhooku@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net>
References: <CAN1APdcCdPGVEHJh4FiQBirunHUxY7HV_idYPtyQT09Fe-fSUw@mail.gmail.com> <CANatvzzMhYowiCCCz+_q+zT6LYRjDa9ru33G-tcs44G8r8cBjg@mail.gmail.com> <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com> <CANatvzyDZ_Wf9wR9WbvsdJzMuQOjnMHfFwWu-VZ4wVN-QF4How@mail.gmail.com> <CAN1APddn19A1xO74wwSDte5qjjtJC7o2gGi53JW22jcTm89iJQ@mail.gmail.com>
To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
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.18)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vrOkxCz7CUqfc4pVysanN5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVita7dq4C5XeXlPLezMaOVjs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYV02484zECfle5vrwArTB04jUSEF1DKGQ k5uEolWDqGJz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVi5bZXEudL3ieMOBM2bJNcVYE7tCqypI5WX0qWh4YQLCDiFcTNEuokWVE +92LapjBbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXYENHEHdfH4WKtOnkQjvURQKHY 6H+wSCoVvwvquzDDiAFgqbLsMBS3CSu0TYW/KPOYdub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/A8XCt5mXqmNwVvS5gBXA-1i2DCk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 28 Jul 2018 14:41:26 -0000

I think that Kazuho is making a strong point. The PNE is somewhat malleable, so there is indeed a risk in not using AEAD to protect the encoding. 

There are potential gains in not including the encoding in AEAD, but they are pretty small. There is no actual need to decrypt the PN in place and modify the input buffer. You can always decrypt it in a secondary buffer and use a scatter-gather API for AEAD input. Or you can copy the entire decrypted header in a secondary buffer if you don't have access to scatter-gather API.

-- Christian Huitema 

> On Jul 28, 2018, at 6:44 AM, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> wrote:
> 
> You can have one core with access to an input queue that does nothing but decrypting packet numbers.
> The decrypted PN’s are placed on a queue.
> Meanwhile one or several other cores verify the AEAD tag and places validation on a queue.
> A third set of cores processes decryption and places decrypted packets on a queue. High priority frames are read from the decrypted packet queue and processed, pending tag confirmation.
> A fourth set of cores deal with ACK processing and other packet number sensitive content.
> 
> If the original receive buffer needs to be modified, you first incur the PNE decryption delay, then you force a possibly shared cache line into exclusive mode by writing to the buffer. The separate concurrent stages now not only have to wait for PNE, but also for the inter-processor cache coherency synchronisation to take effect.
> 
> For encoding there are fewer benefits, but one is that you can encrypt buffers without deciding the packet number immediately. This might be helpful if sending via multiple cores feeding to a final transmit process that synchronises packet numbers and applies PNE before sending data on the wire.
> 
> 
> Kind Regards,
> Mikkel Fahnøe Jørgensen
> 
> 
>> On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:
>> 
>> 2018-07-28 7:11 GMT+09:00 Deval, Manasi <manasi.deval@intel.com>om>: 
>> > About the issue of Packet Number Encryption outside of AEAD - We agree it simplifies both hardware and software logic. It also allows the2 encryption operations to run mostly in parallel, so it is a welcome modification. 
>> 
>> Would you mind elaborating a bit on how the proposed change would help 
>> parallelization? 
>> 
>> My understanding is that it does not help parallelizing "encryption", 
>> because the only change is if you have the cleartext PN (which is 
>> something you can prepare beforehand) as part of the AAD. 
>> 
>> I also do not understand how it helps parallelizing decryption in practice. 
>> 
>> The proposed change removes cleartext PN from AAD. It sounds like that 
>> you would then have a chance to start processing AAD for GCM. But I am 
>> not sure if that is correct. 
>> 
>> In the current approach, input to GCM is: GCM(first-octet || CID || 
>> plaintext-PN || payload). 
>> 
>> With the proposed change, it becomes: GCM(fist-octet || CID || payload). 
>> 
>> Because where the payload begins depends on the value of the PN being 
>> decrypted, in both cases you have the same degree of parallelism. You 
>> can process GCM to the end of CID, but no more. 
>> 
>> To conclude, I do not see how the proposed change helps parallelize 
>> the encoder or the decoder. 
>> 
>> > Thanks, 
>> > Manasi 
>> > 
>> > 
>> > -----Original Message----- 
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema 
>> > Sent: Friday, July 27, 2018 6:43 AM 
>> > To: Kazuho Oku <kazuhooku@gmail.com>om>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> 
>> > Cc: IETF QUIC WG <quic@ietf.org> 
>> > Subject: Re: Packet Number Encryption outside of AEAD 
>> > 
>> > 
>> > 
>> > On 7/26/2018 9:14 PM, Kazuho Oku wrote: 
>> >> Consider the case where a sender encodes a packet number using 4 
>> >> octets even when just using 1 octet is enough. 
>> >> 
>> >> An on-path attacker rewrites the packet by applying XOR 0x80 to the 
>> >> first octet of the encrypted PN, and trimming the latter three octets 
>> >> of the encrypted PN. 
>> > That attack does not work, because the encoding of the PN is big-endian. 
>> > The actual packet number is in the fourth octet. Or rather, it only 
>> > works in the special case where the PN is 0. 
>> > 
>> > -- Christian Huitema 
>> > 
>> 
>> 
>> 
>> -- 
>> Kazuho Oku