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

Felix Günther <> Wed, 03 June 2020 07:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 294463A0C9F for <>; Wed, 3 Jun 2020 00:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RMoYhqk_I6Kj for <>; Wed, 3 Jun 2020 00:14:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DC113A0CA0 for <>; Wed, 3 Jun 2020 00:14:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AFF1DC6022B for <>; Wed, 3 Jun 2020 00:14:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591168475; bh=HiqK/Q6J04yL6uoxu+g9QS3mFcCe6fPqmHweDrtzebA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rCGq3CyNwMpMcGdpFVKStlci8zMG+g0polylutD4OgvWuHlu6POR4Bdy2ytBVmERP B2Ts3R2Up1fYQpYGPsb9Wxro5zNAKubTSSmsQzCMzb/ONHwWg+qYLXGbfcDAbWe5D5 dJC3j0SndKNmfDIsV3oUSv2Zm6vFZtrdjKTHcCV4=
Date: Wed, 03 Jun 2020 00:14:35 -0700
From: Felix Günther <>
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_5ed74ddba107b_18053ff886ecd95c875740"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: fxguenther
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: Wed, 03 Jun 2020 07:14:38 -0000

As already mentioned, there's little analytical support regarding key updates in QUIC (and DTLS), including [our analysis]( As stated for DTLS, my understanding is that some form of authentication of the epoch number would be helpful for a clean analysis.

My thought is: with QUIC's current approach, you could _in principle_ have that the key+IV across two epochs collide, which then would mean you can replay packets across those two epochs. If the epoch is authenticated through the AAD, that's prevented. With XOR-ing into the nonce it's more messy, as now you could have a colliding IV 'cancel out' the XOR (the same affects DTLS, actually).

That said, I would expect the concrete loss for key+IV collisions to probably be an additional birthday-bound term in the order of  #epochs^2 / 2^{|key|+|IV|}. Here, I am thinking of #epochs = number of epochs in a connection, coming from an/our analysis viewpoint on the full channel. In extending that to multiple keys one would usually want to abstract out key generation and assume key/IV across all epochs to be independent, hence the birthday bound.

Martin pointed out to me that (a) #epochs might be reduced to the number of currently active epochs (2-3), and (b) |IV| might be too much due to the sequence number range, which may lead to nonce collisions between ranges.

So, overall, while having the epochs in the AAD might be cleaner from an analysis point of view, I don't have a strong basis for that and think no-change likely comes with a small loss only in comparison.

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