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

mjoras <> Tue, 26 May 2020 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91FCD3A0A78 for <>; Tue, 26 May 2020 09:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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_32=0.001, 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 2Wx9ESxtyp2X for <>; Tue, 26 May 2020 09:42:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D85DF3A0A62 for <>; Tue, 26 May 2020 09:42:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5880A26047E for <>; Tue, 26 May 2020 09:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590511365; bh=60bQh1jxrsMyFYIRXzkDJSXi6fgKeaAiDUHAvWJbp+c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IB/fVMQP1I6Yx+Zpz+IcO1vk3DBz2ou48IHYu1TjJYrRGFH86MTthS78Y4OcovxZZ u9/OtXMbAIwrJAxlhJ56CG+VgqUoEa9YqMxgzDxsBGoMoTXZRawx1UHDNhqixBNL5m BTjp/T5yE9NOnxEACYO3t4q/4gvbUwtY6viVezS4=
Date: Tue, 26 May 2020 09:42:45 -0700
From: mjoras <>
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_5ecd47059a4e_2a913fd241acd96c401171"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mjoras
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 16:42:48 -0000

> I disagree with that view. If the specification can be read as such, then I think we need to make changes. A client should refrain from using an unauthenticated signal for determining what to do with future connection attempts. It does not matter what that unauthenticated signal is (e.g., an error code in Initial packet, failed version negotiation).

This is practically impossible. To function reliably on the internet a client _has_ to use heuristics and unauthenticated information in order to provide a good user experience and not overwhelm server resources.

As a trivial example, if I wrote a client which completely ignores things like VN and immediately retries a QUIC connection, I am locked into supporting that version on my server indefinitely. Since my client will now effectively DOS me if I remove support for this version from the server. This is unacceptable for internet scale. Additionally, rejecting a connection post-handshake makes fallback to TCP more complicated -- it is much simpler to use a happy eyeballs mechanism and "race" TCP and QUIC, stopping the TCP connection once the handshake is successful.

I am highly sympathetic to @marten-seemann's point here. As has been said already, we already have 100% reliable and trivially implementable way to interrupt the handshake in v1with version negotiation. Having an additional signal which is more explicit can only help clients making new connection decisions. We don't necessarily have to prescribe what the client does, but we can say why a server may issue certain errors during the handshake.

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