Re: [quicwg/base-drafts] Forgery limits on packet protection (#3619)

Nick Banks <> Fri, 01 May 2020 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 608BC3A13BC for <>; Fri, 1 May 2020 08:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Status: No, score=-2.374 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.82, 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 M3wdTP654b8l for <>; Fri, 1 May 2020 08:19:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 042053A13B5 for <>; Fri, 1 May 2020 08:19:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 09052281AB7 for <>; Fri, 1 May 2020 08:19:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588346360; bh=o0PP/AFNwHDKEs+VJOa1CxYZfPaJttCCkhJ9/smEgbw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=e2E8e5/ZMxtYfhUAE7WGULVW+ld4ipcTq+4i+LF4+aeMWj4MS3Ol1fQ2xf9TY1RVu xjMdy3OtXpIGwseOFjfFi2WTbZNyx1nUk6552sl3ygdlcH4ddTYshskHNBIfAdEFhr HxBjIyPaJ/XfTRFmLQEqRCEw19tQK/CyJ8YgoE4g=
Date: Fri, 01 May 2020 08:19:19 -0700
From: Nick Banks <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3619/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Forgery limits on packet protection (#3619)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eac3df7e9a3d_f8d3fe40b8cd9602644a5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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: Fri, 01 May 2020 15:19:22 -0000

Another (simplier?) option could be to just update keys **much** more often. I've done performance tests with msquic on the effect of updating the key ~once per round trip. There was no noticeable effect on performance. In fact, more often than not, the key update perf tests happen to perform slightly better (within noise tolerance) than without key update.

I'm not suggesting we advocate once a round trip or anything near that; more like every 2^20 packets (or 2^30 bytes?) sent or received (including failed decryptions). As I understand it, this is an ultra conservative number as far as protecting from any kind of attacks, and should be _free_ as far as any performance impact on the connection. This also has the added benefit of exercising the key update scenario more often, which should hopefully improve interoperability of the feature.

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