Re: Packet Number Encryption outside of AEAD

Kazuho Oku <kazuhooku@gmail.com> Sat, 28 July 2018 14:24 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 6F43C130E1E for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 07:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xdrkR5N2KgC2 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 07:24:13 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 C7655130DE1 for <quic@ietf.org>; Sat, 28 Jul 2018 07:24:12 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id w16-v6so3222829ljh.12 for <quic@ietf.org>; Sat, 28 Jul 2018 07:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YJZpOMXyn0jYdau78layerTBt+evLMijT2JKUtTTZsE=; b=gYkMvCcImVlkHzgLYpcaoNL9LumKtKk9m3wh3Oex7Okvht30rJ1SLVy/0ID1EY9rz9 a7RwZcpCSnbsgdeNsVWtYNy59c3ytJnj7tE9kISlMtePGtjd6m49rR6h9j2q7Uu8pMzp 126G9weU+TFn/Hf9wj+NIQlDaHhZnM/P5pfKy0kjs4uqcc7Tib2uVSkQFHNZI3zcyf0f wK+MqzI6CYiadU2sUXQmV5+mgCw/6kdu8lzKY4mxHMSS0hGubpyAUsu573NdnkFu1dNc XUhwMJMiYwKDfbEQnBePS+iOV3hODyKc6iiqLzuPA9oqbesQwdrqFK4eFY/2wcXUYcRx L1Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YJZpOMXyn0jYdau78layerTBt+evLMijT2JKUtTTZsE=; b=hflaH2cUcmmGUAmabwLenPEDcWloF8kOz6LNpocRWNmPTB3UlwGsVQkVwFQRsRb+DV HjtTYvf0HSCWWpGSctqgNEAQgivLobS+vBvPgLhazqFBRCGSu3dX+CaJBSurvAvHYnXs PazwsO4+lFC6Xzv/BQWlDXZzQS5pdoiQ/lv5nk4osSHuwl2drgg/0CcVPVXQBkVeE/HC nvhhLrLZ6nUf6uw1qlSKmpK2z8YXh1l4+gMFTEQ6lN4Ku9K39z3phuqK7BNB29OVJOW5 j+DlgnHtwsGWYeKYIbhXHWi4v5lwznlBlxERIFlZfHU5Qifsj13UUcoTgNEpC3mKUAfg COXQ==
X-Gm-Message-State: AOUpUlE8yxOCq5mz10UJgHcAIA5iuXIz1qBRrrriAJ5VPMEeM1nPOebm 2s61/bV8yQjwCNs8crL48hxpJ39gv9ySK9VPP0ywgA==
X-Google-Smtp-Source: AAOMgpcKgyyn7KV3oSiDHAx2KBrT8ZgBAKIVOlJuxd6y7P0PKLDhSzxEUEv8hb0OCHNzv08tE1YMKwmYxd/nfH3UU5U=
X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr8260545lju.77.1532787851141; Sat, 28 Jul 2018 07:24:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 07:24:10 -0700 (PDT)
In-Reply-To: <CAN1APddn19A1xO74wwSDte5qjjtJC7o2gGi53JW22jcTm89iJQ@mail.gmail.com>
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>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 28 Jul 2018 23:24:10 +0900
Message-ID: <CANatvzwzpw1wrGrzM0HA+vmV9q4sDCY1oK7qTjKPqMquPUAMZg@mail.gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: "Deval, Manasi" <manasi.deval@intel.com>, Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/us5vLK1sJWRIRu1yKl5FmyL61nQ>
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:24:16 -0000

2018-07-28 22:44 GMT+09:00 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>:
> 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.

My point is that you cannot run PN decryption and AEAD tag
verification in parallel, because the input to GCM, specifically the
beginning offset of the ciphertext, depends on the length of the PN
field, a value that becomes available only after decrypting the PN
field.

The input that can be given to GCM is the first octet and CID,
regardless of the proposed change.

In the current approach, GCM calculation needs to wait for the result
of PN decryption, because it is the value that is fed to GCM following
the CID.

With the proposed change, GCM calculation still needs to wait for the
result of the PN decryption to determine where the ciphertext begins,
because the ciphertext is fed the thing that is fed to GCM following
the CID.

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



-- 
Kazuho Oku