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

Martin Thomson <> Tue, 02 June 2020 00:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 715B33A0029 for <>; Mon, 1 Jun 2020 17:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Status: No, score=-1.555 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_20=1.546, HTML_MESSAGE=0.001, 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 xHqtWVK1_qHN for <>; Mon, 1 Jun 2020 17:35:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A1D93A00B2 for <>; Mon, 1 Jun 2020 17:35:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9230E6A0119 for <>; Mon, 1 Jun 2020 17:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591058157; bh=LKY3FllhS42jEOv364SES7r3F3VWtAzS0I0wyOQCTSo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=O/rQjPuRY9aTKRfv6Cm1PXUFjkNqp2Cwn/EYTZQdED7JWjdFFKDkDuz57mGvruYdR SJaX2bVnV0NrCeP9JLhxOko+RQ90n6bgRlliuUzkL+M6cM6YjABRoTX4IJCKxELNGu LGXPlnQl4lmQ5KUruencd0TXf6PDGfDVG1MuLD5Y=
Date: Mon, 01 Jun 2020 17:35:57 -0700
From: Martin Thomson <>
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_5ed59eed82f83_68313fc0be2cd968217079"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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:36:00 -0000

Kazuho, you have the gist of it.  There is no material performance impact.  The base nonce that you xor the packet number with is still constant.  But the theory would be that you don't get confusion about which epoch was used.  The counter-argument being that the keys (and the nonce) should be completely different anyway.

As you can see, the concern is that there is a risk inherent.

As for divergences, it's not divergent from DTLS, which is where this is coming from.  Because the analytical framework for the record/packet layer in DTLS is more similar to QUIC, that makes this somewhat more compelling.

All that said, I'm inclined toward no action myself, but I want that to have a firmer basis than we currently have.  I am prepared to accept that we won't get that though, in which case we will just have to make a call.

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