Re: [quicwg/base-drafts] Get rid of DoS vulnerability in Reserved Bits (#2280)

Martin Thomson <> Mon, 31 December 2018 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A24F12875B for <>; Sun, 30 Dec 2018 22:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 yWEFKvCFwjGZ for <>; Sun, 30 Dec 2018 22:41:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B9A112867A for <>; Sun, 30 Dec 2018 22:41:31 -0800 (PST)
Date: Sun, 30 Dec 2018 22:41:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1546238489; bh=buN4LzMMbIYiPVzcLxtv2+UeCgFj0I5a4fLE8R6WpQk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BLaenyQYnfsewGqUzST/bDW/+qCMpuMQ5n4EkpnJGhXSJPmKH12sMG7dM9l8KvkMg QiQ/lqj97saUsQeokP+O7scxd7A6dxuRcNZ7iZCwTHPoBlCYjVd4XSNtXEXmhyGw5g gijb1qTk8dyydcvFnhpGCM9ea1ovskrz8GJpPyyU=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2280/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Get rid of DoS vulnerability in Reserved Bits (#2280)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c29ba19b9a9e_774b3fd6cbed45b814752a"; 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: Mon, 31 Dec 2018 06:41:33 -0000

This requirement exists because if you only remove header protection then throw the packet away, you create a side channel that allows an attacker some leverage on your header protection keys.  [The TLS draft]( says:

>  For authentication to be free from side-channels, the entire process of header protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side-channels.

Yes, it's perverse, but there are lots of cases where extra work is done to avoid creating side channels.  This ain't static RSA and the attack here isn't a Bleichenbacker attack, but there are good reasons.  And if you are suggesting that this sort of timing can't be observed, that's proven not to be the case before (see [NetSpectre](

As for a DoS vulnerability, there are two bits, so you will be doing the work for 1 in four packets anyway.  And it's not hard to find packets with valid sequences.

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