Re: [quicwg/base-drafts] Include epoch in the AAD or the nonce? (#3661)

Kazuho Oku <> Tue, 02 June 2020 00:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82DE03A16EF for <>; Mon, 1 Jun 2020 17:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.84
X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9pCItq3-B_dW for <>; Mon, 1 Jun 2020 17:16:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9D433A16E9 for <>; Mon, 1 Jun 2020 17:16:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFC2D2C0E7A for <>; Mon, 1 Jun 2020 17:16:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591056975; bh=ZfuwqAvjcfDL1EPSWCY3i76EKWMMxZ3pTjeQ65lUgfY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BCTNH/YTW/qmD80NqlAVTD3DqWImTybWjEYhsz7t8zk8ygswaeW1PEEt3FR0ZZcvw LT1E3muNb9iqVcN/aKO1bMABn/r98ovFe8Ys+KIPW3synCUBphZSGygmqS4nda5fIO 2qu2VRaM9rpdfFrPCLzE2PHK/YcT0kURPmjq+ePk=
Date: Mon, 01 Jun 2020 17:16:15 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3661/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Include epoch in the AAD or the nonce? (#3661)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed59a4faedc6_73743fc0ddccd96c23228c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jun 2020 00:16:19 -0000

As as implementer, I hope that this issue will be closed with no action, assuming that we do not have strong reason for making the change.

Up until now, we have tried hard to have minimum divergence in the record encryption algorithms being used in QUIC and TLS. We use HKDF and AEAD the same way, with the only difference being the labels. The proposed change would be a departure, as it means that the AEAD layer of QUIC would no longer be using a sequence number, but rather a tuple of epoch and a sequence number.

It does break the existing AEAD API of picotls, as it assumes the use of a 64-bit sequence number (this might have been a shortsighted decision, but anyways).

> With that said, as you observed in our call today, it seems like there is an easy fix: both AES_GCM and ChaCha20/Poly1305 take a 96-bit nonce which we are just left-padding with 0s. If we are willing to restrict to <2^32 key changes, we could encode the epoch in those 0s, right?

Am I correct to understand that this is effectively the same as XORing the first four bytes of IV with the epoch? I think that is the case because the moment an endpoint changes the send epoch is when it moves to a new set of key and IV.

Based on that view, I wonder what the benefit is by changing IV from _HKDF<sup>epoch</sup>_ to _HKDF<sup>epoch</sup> XOR epoch_ is. I'm eager to admit that I do not understand the problem, but I would assume that, when applying HKDF multiple times, we do need to retain a counter counting how many times HKDF was applied, and then mix that into the output.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: