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

Kazuho Oku <> Tue, 26 May 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB9A03A0838 for <>; Tue, 26 May 2020 14:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.1
X-Spam-Status: No, score=-8.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_DNSWL_HI=-5, 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 4BUW7mKLFp2o for <>; Tue, 26 May 2020 14:21:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 321243A082E for <>; Tue, 26 May 2020 14:21:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 427CD282D80 for <>; Tue, 26 May 2020 14:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1590528074; bh=kHAKSXyQld4dYhExFeZ4kpWAoTuIIROIVB7Q8Bb0Hcs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tIvfI2PJ4l+ErNgkhBI9Vm9xIud9SJvfqr9Xml/iws3pNDFPIQuIPOMpZYsi7vBun 0VIFDsowuDUmGnJyybWvRaffxxZrd7M4HZvkO8LeM1I2HNchqzFS5ZDpb/0hLFYy2b sFadF0CydmmKP9qdegb/FCTsJiP9iVBZMfrq4iMY=
Date: Tue, 26 May 2020 14:21:14 -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_5ecd884a33e2a_124e3fb6d24cd95c117976"; 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: Tue, 26 May 2020 21:21:17 -0000

@mjoras I'd emphasize that the specification does not talk about happy eyeballing. We should concentrate on discussing what to do when only QUIC is being used.

Having that said, I'd hope that we can agree on one principle: QUIC cannot respect unauthenticated information any more than TLS over TCP does. Otherwise, QUIC becomes more prone to MITM attacks that TLS over TCP is - a disobedience to our charter.

>  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.

That *might* be true, but our experience with TLS over TCP is that we do not need an error code for the purpose.

> As has been said already, we already have 100% reliable and trivially implementable way to interrupt the handshake in v1 with version negotiation. Having an additional signal which is more explicit can only help clients making new connection decisions.

FWIW, you do not need a version negotiation packet. Per my understanding, any server can send a private error code. Or a reason phrase explaining things.

> 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.

Am I correct to understand that the reason you are advocating for having more error codes is to allow a server to control the behavior of client for future connection attempts? Assuming that is the case, I'd oppose to having such error codes regardless of how we would describe them. Because IMO that is effectively about making QUIC more prone to attacks than TLS over TCP is.

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