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

Kazuho Oku <> Sun, 24 May 2020 11:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C93F13A0846 for <>; Sun, 24 May 2020 04:01:45 -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 rsYFEq3GEV6u for <>; Sun, 24 May 2020 04:01:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DDD83A084D for <>; Sun, 24 May 2020 04:01:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 575ED52003A for <>; Sun, 24 May 2020 04:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590318101; bh=2KBtNO5dNAmdzRvE7mfQxSFTjpyJZJ7nQ7ZvsDwXAWg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=07vQ6ndAAqqfFoJJBnEHtCbR6ZjjlwZJ+XdduJijzkgYmHVUTQfKoqxgXm2XmmLV7 tf1w1jbOpYnImVrC1ZVhXw/ZlexuGRMwvF5KozUDwMTJ8WJ37mbnmumXN4CH1xl8Qs nPgikwUGNH/yX8/F/mqWKND3Ihs1F0nXUuFAKTcI=
Date: Sun, 24 May 2020 04:01:41 -0700
From: Kazuho Oku <>
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_5eca5415476a1_62603fc9afacd95c868927"; 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: Sun, 24 May 2020 11:01:47 -0000

I tend to think that adding an error code that affects client behavior is not a good idea, when that error code is intended to indicate a handshake failure. The signal carried by an Initial packet or a Handshake packet is not authenticated, and we should be wary of using that to convey something that affects more than just that connection.

> * INVALID_TOKEN: try again immediately
> * SERVER_BUSY: try again after a few minutes
> * CONNECTION_REFUSED: don't try again for a day / week or so

In case of this example, CONNECTION_REFUSED would become an attractive tool for MITM attackers, because it can be used for preventing the client for reconnecting for as long as a day or a week.

If we need these signal, I think that they have to be carried at the application-level after the QUIC handshake concludes. In case of HTTP, we already have 503 + Retry-After header field.

To summarize, I think my position is:
* We should not add error codes that affect the client behavior after that connection gets closed.
* We might want to get rid of SERVER_BUSY, or at least state that a client cannot really tell if the server was really busy, as the signal is not authenticated.

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