Re: [quicwg/base-drafts] Clarify Actions on nonzero Reserved Bits (#2280)

Kazuho Oku <> Thu, 10 January 2019 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EAD7128766 for <>; Thu, 10 Jan 2019 04:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 oaFNfGwmcj_E for <>; Thu, 10 Jan 2019 04:58:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFD90130F81 for <>; Thu, 10 Jan 2019 04:58:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=4XPFLFf8zgTh4edhf64sI2ydMZs=; b=izkzagt0AYc9WOGw sgakEKUSjfFr30wcvr6bK8UfKI9FufrtF+VaFdzs+n8QRhv/5W2/O5WBm5cYlG80 SnrQg5NdoVJCAt35K+DhlQZOL6L4kql741tKSUFDOMYApET6KTmts5O/V4iTL29X jx0GV9aN3B/yWWnbHbbpeeQwk8g=
Received: by with SMTP id filter1389p1mdw1-20200-5C374185-16 2019-01-10 12:58:45.638019128 +0000 UTC m=+213326.634613874
Received: from (unknown []) by (SG) with ESMTP id CLYKaorXQp-C6HQivmXo8A for <>; Thu, 10 Jan 2019 12:58:45.586 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 8D410A802CA for <>; Thu, 10 Jan 2019 04:58:45 -0800 (PST)
Date: Thu, 10 Jan 2019 12:58:45 +0000
From: Kazuho Oku <>
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] Clarify Actions on nonzero Reserved Bits (#2280)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3741858be70_6c73fd0634d45b83816c5"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3iVyhd0gDo9BoaTUntUj4c7RiVQi6PHbX4wV tu2H4OcegxeQfoWFB5rh35ttW60h0xC6sa+Sy53i5vLsePqrzmefmrkFzkPWnsjNEUxH3Ksp8km9SZ Cgx+vAJ3yfRwoD3942tDhw0byVqHY8PklOznKhtixa8sh1BDbM+Z48EzOWE3vkU2MQ2T/noYomGq4a U=
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: Thu, 10 Jan 2019 12:58:49 -0000

> Saying they have to be 0 invites people to short-cut the full decryption and drop packets that have other values immediately.

Honestly speaking, I am not sure short-cutting in case the zero check fails would lead to side channel vulnerability, considering the fact that a failed check immediately ends up in connection termination. The only information an attacker can obtain is that the sender failed to set the bits correctly.

Anyways, I do not think that removing the zero-check dissolves the vulnerability to the side-channel attack, because any use of the bits protected by header protection prior to AEAD-decrypting the payload is forbidden. The real attack exists on the PN field, where an attacker can flip the bits of the encrypted PN and use the timing difference of the receiver that short-cuts AEAD decryption based on the value of the PN to infer what the value of the unprotected PN was.

Therefore, I think that we should spend our effort to be clear about when the unprotected header bits can be used, rather than trying to fixing a use-case that does not have a high impact.

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