Re: [quicwg/base-drafts] Allow server to enforce post-Retry packet numbering (#3989)

Kazuho Oku <> Wed, 02 September 2020 03:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87B493A0AB1 for <>; Tue, 1 Sep 2020 20:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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] 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 MxnqW5NjGMdq for <>; Tue, 1 Sep 2020 20:23:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCD053A0AB4 for <>; Tue, 1 Sep 2020 20:23:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA181600E1D for <>; Tue, 1 Sep 2020 20:23:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1599017015; bh=g/FF7NhKBHnScxYLRmpVdRmg7fCmYENTMk6qMDlsLBo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=v3y2mkkS4ska/aqY+ul7QWLS0pY97/wbKzsnnLCDyca64mR16WWiBC/XkOsNp5wJ6 DAqDOLY/ydRccCvEW0Ji9Xuewf7RcxoaPu44D/6BQlYMAE4bXISQKcW0BppyO106u7 L4ZFqnjdVEAVtVQL6b8ZsWrLGB9GrvN8XQaKGKbU=
Date: Tue, 01 Sep 2020 20:23:35 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3989/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Allow server to enforce post-Retry packet numbering (#3989)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f4f1037d8d23_37df1964655e4"; 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
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, 02 Sep 2020 03:23:39 -0000

As stated in, detecting MUST violations for Handshake and ApplicationData packets is fine because they are protected by the secrets, but not for unprotected information.

Therefore, it makes sense to have a MAY here.

My limited experience tells me that we have different customs between WGs. I tend to believe that document produced by TLS WG assume that a MUST implies "peer MAY detect." And that's fine because TLS does not care about attacks against the underlying transport, and hence any violation is considered as misbehavior of the peer. In contrast, MUST in the recovery draft is not enforceable at all. HTTP is in a middle ground, HTTP/2 has many MAY detect rules for misbehaving peers. That might be due to the history of HTTP being a very lax protocol.

I know that the differences are confusing, but I think they all have reasons, and am perfectly fine with keeping status-quo.

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