Re: [quicwg/base-drafts] Confusing SNI recommendation in the HTTP/3 spec (#3324)

David Benjamin <> Tue, 07 January 2020 23:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E0CF120025 for <>; Tue, 7 Jan 2020 15:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 rITaIkI19BxA for <>; Tue, 7 Jan 2020 15:42:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C866120018 for <>; Tue, 7 Jan 2020 15:42:46 -0800 (PST)
Date: Tue, 07 Jan 2020 15:42:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578440565; bh=MFEymqrCb5uCs478GzS+jjoWeu7e7f1FAD96hz/UdfY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VDG08bibZDdJICmrGLAtB4Z2LD8a9q7sLiQn+TTqNlgn/eAgqOEL+Dq2mi1jgodJx s/X7jfUbkkduwmBZQkbBygdqDO/VAawSe9zpv6ymFbtGRS+ULN/5eEpVP0bI9y+Yzh 4DcW4thBPXFUNRrLihux9HPj32BDiqf1NRPnctdw=
From: David Benjamin <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3324/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Confusing SNI recommendation in the HTTP/3 spec (#3324)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1517755c715_58153fd0548cd96c1055d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: davidben
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, 07 Jan 2020 23:42:48 -0000

For HTTP/1.1 and HTTP/2 over TLS, we do not send the IP literal in SNI. Chrome accidentally did for few releases, which broke Apache httpd. It got confused because IPv6 literals have colons. Of course, the compatibility issue does not apply to a new protocol like QUIC.

It would be nice for QUIC to mandate SNI, and, all else equal, avoiding random TLS inconsistencies is good. But this rule is odd and "you MUST send SNI whenever you are supposed to send SNI" is tautological. TLS 1.3 says something woefully noncommittal:

>    Additionally, all implementations MUST support the use of the
>   "server_name" extension with applications capable of using it.
>   Servers MAY require clients to send a valid "server_name" extension.
>   Servers requiring this extension SHOULD respond to a ClientHello
>   lacking a "server_name" extension by terminating the connection with
>   a "missing_extension" alert.

I dunno, everything is a mess. :-( If we were doing things anew, perhaps we'd have stuck the port number in there too. (As it stands, TLS does not authenticate the port, yet the port is part of the origin, and I doubt HTTP servers reliably check the port in the Host header.)

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