Re: Packet Number Encryption outside of AEAD

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sat, 28 July 2018 15:13 UTC

Return-Path: <mikkelfj@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 9CDFE130F88 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 08:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 goSBdKqGDnMS for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 08:13:16 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 17AAB130E76 for <quic@ietf.org>; Sat, 28 Jul 2018 08:13:16 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id q19-v6so6493113ioh.11 for <quic@ietf.org>; Sat, 28 Jul 2018 08:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=I/j+rilTokxewbiFz3fHApk/s6xctJSOlAahP9JBv/M=; b=unCd39Ghg5mtignn1SL6Q1RDKcZ/0sYt6REct3ZmzPmL3bQhWiufJDRf3PyLgpuPD5 G0O5O/5WyZC5ZeHe4qzWrj0y8QCI69yPYsVW3rMLl65MLD0ag1bQXnj2WKexDtk8rMtJ /JDZi+TkdcxV9LIaqw73Fj90ASlwZaEz318ISJHjSv8rPTMHkjrADuifxSsfgXMkKe6O wjD9osttMy6y1+Pa09IjOrG6vy+PmlZzYIo4rG+2Sg65Vkh6pCMgB4BIPpaRRkkjIIEK PNVQK4MlAZ8pYsFTgOff2Y0hb/oXsaHzWedW70gm11nfL3vMcwAYnOiuAyHI33jUEEbe p7WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=I/j+rilTokxewbiFz3fHApk/s6xctJSOlAahP9JBv/M=; b=kKhLAkot8jE6sfX+T4k/N0S8fLel9f/QNhRDyp0P33HQ7VzlJnLqqg8RWaCbQpfRub 0fBIpEkLvr2i/fGlIU6ummYQoql7Mx50R5MCKL3BmIld/1wRrVF4FnLDnHWA4t+lL0Sf 2iELK+Tn28V/AZRcz/JvGHZiHnUJbfrKxtSBNlwrLQfuOFgijWMwwgbVX5Pi5NayRTcn q5b6/UErYUBINAsMa3i3vy5qNtKso+UtriDxrY7aph5ZaG0KxE7je+DRUDvWb0R/ZAcn HsluKK7cq97Sn60+DUa7Hdqs9HH8ntGDgGEQnakKSZv1XSzGpSAAnaqBbzHHW6yEC/Al ChMQ==
X-Gm-Message-State: AOUpUlFga7mC0thT23WL4RdKiSz0TXtC7HDsChSi7//J9GVZlNuM65L8 mt36U7utgxaJdIygG3jpsxELrSj5sT8R6PYJ0lk=
X-Google-Smtp-Source: AAOMgpeeE15RFRQYdr5fWK47663NPFeqSKRdnsw8fHs9U+iYiermLYOmgNIVC9OBmcbHA9cTH+x4uHP1b3xzS/TLzCQ=
X-Received: by 2002:a6b:7b03:: with SMTP id l3-v6mr8962975iop.36.1532790795457; Sat, 28 Jul 2018 08:13:15 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 28 Jul 2018 08:13:14 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <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> <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sat, 28 Jul 2018 08:13:14 -0700
Message-ID: <CAN1APdcFLkdUpy9mB_8N=ONfyePpeP_RK8o+ruQqaYZmZeVnNw@mail.gmail.com>
Subject: Re: Packet Number Encryption outside of AEAD
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>, "Deval, Manasi" <manasi.deval@intel.com>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e0dacf057210aad5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2c8ALXspD_CdMwxI_5BIeBOLnDU>
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 15:13:19 -0000

Yes, the fact that you don’t know the PN length is a problem.
The PN length could be sent in clear text. Would that be a problem?

Copying is not very useful if you want to pipeline packets.
A gather API can work but it complicates things, especially in hardware.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 28 July 2018 at 16.40.43, Christian Huitema (huitema@huitema.net) wrote:

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