Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

Martin Thomson <> Tue, 26 May 2020 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A53AF3A0BB6 for <>; Tue, 26 May 2020 16:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Status: No, score=-1.483 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_24=1.618, 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 ea03uU2ANdbV for <>; Tue, 26 May 2020 16:27:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 393083A0BAA for <>; Tue, 26 May 2020 16:27:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFB26280ABC for <>; Tue, 26 May 2020 16:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590535620; bh=+ZZCDusFojMArVoExQVn8bYRl649hygOk/BDG3/DhOQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EoDYipPefRjmckHVoP+HNwosocBRBA+3vynm0y75BhyLmB8z05Uz9quTAOInfW9Wv SO0o+vNWtjok58vl19+Rh6hIVpJRke4oXDvsenZjYXlCpaqlCW+9wjzg1s/V6MzEWD QCo5wSeZxqglWiXz7lsOvW4aqpltTbwP4OTHP15Y=
Date: Tue, 26 May 2020 16:27:00 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3690/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ecda5c4bf6ba_80a3f858bacd960775c9"; 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, 26 May 2020 23:27:05 -0000

I think that @kazuho is entirely right here.  The renaming of the error code is useful as it removes the *implication* of a semantic that would be destructive.  That implication is that the code is like a 503, which comes with the *further* implication that holding back for some time is desirable (due to the common use of Retry-After with 503).  QUIC has no Retry-After, so any implied time delay is bogus.

As mentioned, that browsers might sit and wait is a policy decision that makes sense in the current state of the world.

I'm going to merge the PR.  But I get the sense that this is not directly addressing the issue.  For the issue itself, I think that the only real resolution is: that's tough, but too bad.  As numerous people have said, this phase of connection establishment is ripe for DoS and we have chosen to accept that risk in QUIC version 1.

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