Re: Packet number encryption

Mikkel Fahnøe Jørgensen <> Thu, 01 March 2018 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 878A012FA94 for <>; Thu, 1 Mar 2018 11:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pb86bpzXgOss for <>; Thu, 1 Mar 2018 11:58:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E650212FAE2 for <>; Thu, 1 Mar 2018 11:58:35 -0800 (PST)
Received: by with SMTP id h23so8386994iob.11 for <>; Thu, 01 Mar 2018 11:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nKtQKO4ClEuesrFtKzQ55nz8q4hP1L1+QNhkYyg6+eg=; b=uRF12sAZpdmP9VxkgetqrW1MwDU3OzfhC+AppoEL6+vvnEN+yyQGaHZIkd49vgbir5 wtO0ZmvkwsL5uuudgNRTh405axRJ4B4B+/4UpDTQdLis6TtCjoCFFPMrMTVyIQdA/Rln bof6o30FHZejo0mgAXbNmFtsF44qKVr1pmvilJ9iQX5eh1FlgYGePnnG9L2MxPA3nu5O 5XW113AHpT/n51YIdcIgvHBbfAmwtmJEXiho4AzBGMU2B+7BSMGhFzSaymWVGsd54f2m El1CQMC7Z+pY6j1fyO2FO0G0+W6woC+5OzQGhwv0elW9XDfh5xWdznZJzaNKRM8Nou9r bUcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nKtQKO4ClEuesrFtKzQ55nz8q4hP1L1+QNhkYyg6+eg=; b=ZmjYzWnn3aB/eXX9iRF2IB3U1JwIKl/3W3UXOzlEO7EQrespJyoIFE0avCLEVNV5GP oe0OWgGsp/5cmFjWDqBIikBoKriiPUt/p+pM+YPEsHy4tTVwpcl+XQipwteofFCFVNzA 4HcMx4GDYlltR+v6SoyyA4S5DUw6wsw1SsgesW2QQF2Oi38ZfyYRLXZzwaCtoIQy5zv9 MzYtu1nvbqgI0hPJoN6rkNJjvjjxV6JFdggWzeqCYau7ySye478otrV50rDsf4CKjGX1 wRdKBqGq5DhMhJ6yivrDnQF5NBG4AhAUN8bV6a/b30f3CEosyIfKI4kLmLrQAwEA6RvZ I1cw==
X-Gm-Message-State: AElRT7HeEQaitqwfFx7GF5wTnv9IyfBCWaGDOp+BYpQG9YXekVVBRHQg hxRHH55JqpjVKxonXknI8d4jshPR4oU9ptVS/fQ=
X-Google-Smtp-Source: AG47ELv3KSuiLeJlH56K48LDF1+m8wa5MI4I+GvygCahr60c76P3n8IYoxSSW1QqAd5FSn+rI4hF+VOLdi9vVcvcyMk=
X-Received: by with SMTP id n139mr3624542ion.165.1519934315238; Thu, 01 Mar 2018 11:58:35 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 1 Mar 2018 14:58:34 -0500
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 1 Mar 2018 14:58:34 -0500
Message-ID: <>
Subject: Re: Packet number encryption
To: Eric Rescorla <>, Ian Swett <>
Cc: Jana Iyengar <>, QUIC WG <>, Roberto Peon <>, Mike Bishop <>, "Salz, Rich" <>, "Brian Trammell (IETF)" <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, Stephen Farrell <>, "Lubashev, Igor" <>, Praveen Balasubramanian <>
Content-Type: multipart/alternative; boundary="001a1140444af11ba105665f482d"
Archived-At: <>
X-Mailman-Version: 2.1.22
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: Thu, 01 Mar 2018 19:58:39 -0000

While considering some redundancy scenarios it occurred to me that packet
number encryption could interfere with integrity checks in middleware and
in cooperating servers:

A server might forward a packet only if it passes an integrity check.

AES-GCM encodes it tag based on the cipher text. This means that it is
possible to verify packet integrity without decrypting the packet first.
This not necessarily true for all schemes, but servers might rely on having

It might be relatively easy to decrypt a packet number considering that you
need a key to verify a GCM tag anyway, but it does depend on the final

It is possible to verify the tag without being able to decrypt the content
because GCM splits the traffic key into an encryption key and a GHASH key H
provided that H and IV is available. This does not in itself prevent
content manipulation, but it does prevent reading the data in clear text.
One could also imagine other encryption schemes not found in TLS 1.3 better
suited for such tasks.

In either case, packet number encryption would interfere with such
validation unless the output of the encryption is the IV used for that
packet, or the clear text content is leaked.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 7 February 2018 at 02.05.27, Ian Swett ( wrote:

Thanks Jana, I think this is a nice framing of the problem and discussion.

On Tue, Feb 6, 2018 at 7:13 PM, Eric Rescorla <> wrote:

> On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar <> wrote:
>> I'm going to try a different attempt at moving towards
>> convergence. Thinking about this some more, and picking up something that
>> Mirja said way earlier in this thread, I think the following decomposition
>> is useful.
>> 1. In the transport, all packet numbers start at 0, increasing
>> monotonically. ACK frames carry these packet numbers, and therefore do not
>> have to span large gaps and do not have to deal with increases in the size
>> of the largest acked. Basically, no gaps are visible within the transport
>> processing engine.
>> 2. Before sending a packet on the wire, and before processing the packet,
>> QUIC transforms the packet number with some function, replacing the visible
>> packet number with the transformed value.
>> I think we can all agree that (1) is goodness. A sender is also free to
>> use packet numbers from non-contiguous spaces here FWIW, but that's
>> entirely independent of what's visible on the wire. This helps me separate
>> transport processing complexity from the rest of it, which I think is
>> helpful.
>> I think we are disagreeing on the precise properties we want from the
>> transformation in (2). If we can agree on these properties, we can then
>> figure out whether it's possible and how to construct such a transform.
>> Here's a union of what folks are concerned about:
>> 1. Packet number must be unlinkable across connection ID change (for
>> migration.)
>> 2. Packet number must start at an arbitrary value, to avoid ossification
>> of the first packet number.
> 3. Some sequencing information -- a few bits of the packet number perhaps
>> -- should be revealed (for monitoring. Number of bits TBD.)
> I'm not sure I am persuaded of this point

Yes, I think this seems like the largest point of contention, and #4 is the
second largest concern.  Given that, I think it makes sense to try to
resolve #3, if that is possible.

> -Ekr
>> 4. Any packet number transformation should not be compute intensive.
>> I'm not looking for a construction, but I'd like to agree on the problem
>> first. Does this sound like the set of properties we want? Or is there a
>> contradiction among these properties that I'm not seeing?
>> On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop <> wrote:
>>> Packet number encryption *does* improve linkability equivalently to
>>> random jumps, but without the fragmentation of the ACK packet which those
>>> jumps otherwise cause.  So I'm with Stephen, we don't yet have agreement on
>>> that assertion.
>>> -----Original Message-----
>>> From: QUIC [] On Behalf Of Stephen Farrell
>>> Sent: Tuesday, February 6, 2018 7:35 AM
>>> To: Mirja Kühlewind <>ch>; Mikkel Fahnøe
>>> Jørgensen <>om>; Brian Trammell (IETF) <>ch>;
>>> Jana Iyengar <>
>>> Cc: Praveen Balasubramanian <>om>; QUIC WG <
>>>>gt;; Roberto Peon <>om>; Lubashev, Igor <
>>>>gt;; Salz, Rich <>
>>> Subject: Re: Packet number encryption
>>> On 06/02/18 15:23, Mirja Kühlewind wrote:
>>> >
>>> > It's also my understanding that we do agree that packet number
>>> > encryption does not help likability (and thereby privacy) a lot, or at
>>> > least that the benefits we might get (or not) do not justify the
>>> > additional complexity.
>>> FWIW, which isn't much, I don't (yet) agree to the above.
>>> I reckon it'll be a while before we know how linkability pans out. I do
>>> agree that packet number encryption is not a panacea for unlinkability, but
>>> it may help, or may even end up being required, to do a good job wrt
>>> linkability.
>>> I also heard people say it was less complex for them so "additional
>>> complexity" may also not be quite right. (I guess "differently complex" is
>>> correct though.)
>>> S.
>>> --
>>> PGP key change time for me.
>>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>>> NewWithOld sigs in keyservers.
>>> Sorry if that mucks something up;-)