Re: Packet Number Encryption outside of AEAD

Kazuho Oku <kazuhooku@gmail.com> Sat, 28 July 2018 18:14 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 BA972130E5D for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 11:14:01 -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 ZDW8xjfXiYU6 for <quic@ietfa.amsl.com>; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 8B7DA130DD3 for <quic@ietf.org>; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id u14-v6so5583174lfu.0 for <quic@ietf.org>; Sat, 28 Jul 2018 11:13:59 -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=GaP/iXwWh0+ZpftxIIX4wsmYogxKVGqvocbdXiaPxs8=; b=U4uA2spmCylbYBVxBxhl9cWqR+p9EWR7IRp7EtIaOvNaW/hsUap6oVf+2qb1O19D1U yDDRQrmPRQwy5buAHdmPKPd1IJGzeMcz87Me2KiAsG5Sw6x8SFzIto7UfsQkQ59fYCO+ nP/4kth+8Bggm/0D/MIc6CMLQh1zoIhKLWcUggEj2iS+Tnm5vywNlu9dxvNfUQ/pyJsF bEz4cxuCr/xtXiw5bV5Obnc9iAFAdtg7sHh4eDv0XygADek/INOh78DFnCIIFwlCUgOx RoBm7hcvYWi0EhwyqD8zc6Fz1dpvLfUskqFf/pZd71MdIbq4I1vkWViEmIykKpAiCnHp BJRw==
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=GaP/iXwWh0+ZpftxIIX4wsmYogxKVGqvocbdXiaPxs8=; b=UdTuWwajt+5rXMFtoLDCYfwC7zPlUJ0XjASig3zAUEbwCHFDz1mfrcabkd9aNW0CXI kffHH3n4El0FrM/Xk0vjclWPQKgGDhxPE0GJZAQSChig/egzNWe3MdKFnC5ObqFq7n1R MTsU8c4voWudZTFqF7PAHtNHbIgppOznwQMVLL8AYj3HLT1lACCpdjlYlZ/4s6NH/NwI zNlwy5OUOJsk92vgxNPQ5zsHOVPmqgFSolNjrD3q+xp51U8q1l99GtR4Sf+vzAiWT4hj 1hRxc9yKgLz83pvzOoIlfDnf3mh1S5PwJHvodkIn5gTGmjBYzCkFkLCxWyKEPmFgNMuI zyDg==
X-Gm-Message-State: AOUpUlEgQfKXQB6mF6pXoXyRKqLQxoOp6+QRIE6cw2YQCwsYCh6OBMkC w5TDWyXhlKt+5Ceng6/GEOPjESTb4fuOYxhx94M=
X-Google-Smtp-Source: AAOMgpfeNOvMYpNqhSWdNipeh6SusAq3aTUnE7pqKxnsrJRlJqkcX2mV51nAMkX8WQupHRe0r7ULCCVrsXx4IsUa0+8=
X-Received: by 2002:a19:de4e:: with SMTP id v75-v6mr6448773lfg.14.1532801637850; Sat, 28 Jul 2018 11:13:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 11:13:57 -0700 (PDT)
In-Reply-To: <CAN1APdcFLkdUpy9mB_8N=ONfyePpeP_RK8o+ruQqaYZmZeVnNw@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> <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net> <CAN1APdcFLkdUpy9mB_8N=ONfyePpeP_RK8o+ruQqaYZmZeVnNw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sun, 29 Jul 2018 03:13:57 +0900
Message-ID: <CANatvzyCoQSZruBezyWv0Yzw6gYk9O7QnjtPAWatkjacMkUHhg@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: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>, "Deval, Manasi" <manasi.deval@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NUQAAfyT-vidN9ZhmkneOMXWb5g>
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 18:14:02 -0000

2018-07-29 0:13 GMT+09:00 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>om>:
> 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?

That would be a problem.

An endpoint can select the size of the PN field based on the number of
packets inflight. For such an implementation, sending the size of the
field effectively means leaking RTT.

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



-- 
Kazuho Oku