Packet number encryption

Martin Thomson <> Tue, 30 January 2018 01:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CFDA1314CD for <>; Mon, 29 Jan 2018 17:59:21 -0800 (PST)
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 qgBbOEbDV93t for <>; Mon, 29 Jan 2018 17:59:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D454131992 for <>; Mon, 29 Jan 2018 17:59:19 -0800 (PST)
Received: by with SMTP id r23so7024547ote.8 for <>; Mon, 29 Jan 2018 17:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ComD55vNZRrMhK3g1lOiHUO72OF0zXquiEuMudQB7Y8=; b=tp8ylm43cEVKEmZvb6umNQGH+SVT3kzIkjlG6cXsxrvcfByezRlwfkGommlJQw4cgg nghlLI/h5UBWPFzp/jFWkex2+z8DtWIV3yo9qTngCZSqvO35GIPKwkboz9jOJSYcnyhn v7U5/7sDL8JNbEiHj9nPstTMA/5T7DUCAFkDJ8SpTmLcDh9TacIsoFzmtq5RGByNBCqC BMS1dHcsh0kfDfAu5jyJWZKqofXfoluIClM3fCJQv8BDIXbIc8eK8iUwXU5/ymSE7aOt wE7bIv7OqF/sAj+A5ChH9fQASl5uCHW05P+2TpZ7kXT1NAOq/JBGfwot5iwZfDif0M8X T0QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ComD55vNZRrMhK3g1lOiHUO72OF0zXquiEuMudQB7Y8=; b=ceVmT1E2LfFSYOYZ3nftq8PbNuUclINc2OsyDxl/dL7kgasIm9Ue8OUx8aDwWMcD0H AeDQYqu8f/J7wd5ZGaGJHSRmRxZ6b/deE3AphhVoudYkUyF3EVh86nAjVSZTdsH7UIEn a5i3h9kj0D0vnzicCAQ11kxVqJqgPAQW3sUzlcyM7D4GpJdWwdoegsuN4q9EeIrOVwZ3 o6wyOo5Gc4Dfigy8FLiTw5vL+0WPB6QUcMcCmPvgbBPTsxoI/PUksdT/6GndN/y40A1+ eLr/j1JdILeBOQqiycdLwFeANWwfFfvOP3dkO/ePdUmslYyp6OtJzA5XDbi5p4OiNz4l 1SDg==
X-Gm-Message-State: AKwxytdvHsYM94IPPJZnfySNdILKhikX6efv2pIfHG4sTzSZbtVUOL/b bJot7JoR1llEqIDaRxf0YTU6XthE8M3IaXFNSri4HpVX
X-Google-Smtp-Source: AH8x2244yRV+c9xhGkwgfdVuAnsUvf+AEMRwXXh0aCxmuj/zQ3Im0w+D5DGXzPSGVSKZC3vh0ocMp+a1We/SeOSBOUk=
X-Received: by with SMTP id a29mr9911834otj.308.1517277558130; Mon, 29 Jan 2018 17:59:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 29 Jan 2018 17:59:17 -0800 (PST)
From: Martin Thomson <>
Date: Tue, 30 Jan 2018 12:59:17 +1100
Message-ID: <>
Subject: Packet number encryption
To: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 30 Jan 2018 01:59:21 -0000

Here's a PR:

In short, this builds on Kazuho's excellent suggestion to use ECB-mode
to protect the packet number.  It does this only slightly differently,
using suggestions from ekr and others to allow for cryptographic
agility and use of primitives that match the negotiated AEAD.

In short, it takes some of the ciphertext of the packet payload, and
uses that to encipher the packet number.  My intuition is that this is
pretty solid, but I want to check if the working group is happy that
this is generally OK before seeking cryptographic review.

For instance, the requirement for side-channel resistance is already

For the record, I doubt that this can be proven to be secure without
both breaking new ground and adding some constraints to the AEADs that
we use.  And that's before we get into actual breaks on the technique
that I'm too thick-headed to think of.  In any case, we're relying on
this to protect against linkability, so I'd like to ensure that we're
not completely crazy in doing so.

In case people were wondering, and because it already came up: I
intend to separately propose a change to the short header packet that
would remove the type field and move the packet number length under
encryption.  See my response to Ian's question on the PR for an
explanation of how this will likely work.