Re: Packet Number Encryption outside of AEAD

Kazuho Oku <> Sat, 28 July 2018 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA972130E5D for <>; Sat, 28 Jul 2018 11:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZDW8xjfXiYU6 for <>; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B7DA130DD3 for <>; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: by with SMTP id u14-v6so5583174lfu.0 for <>; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
References: <> <> <> <> <> <> <> <>
From: Kazuho Oku <>
Date: Sun, 29 Jul 2018 03:13:57 +0900
Message-ID: <>
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
Cc: Christian Huitema <>, IETF QUIC WG <>, "Deval, Manasi" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>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 ( 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 <>
> 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 ( wrote:
> 2018-07-28 7:11 GMT+09:00 Deval, Manasi <>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 [] On Behalf Of Christian Huitema
>> Sent: Friday, July 27, 2018 6:43 AM
>> To: Kazuho Oku <>om>; Mikkel Fahnøe Jørgensen
>> <>
>> Cc: IETF QUIC WG <>
>> 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