Re: [quicwg/base-drafts] Make SNI more clearly mandatory (#3326)

Martin Thomson <> Thu, 09 January 2020 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2653F12004F for <>; Wed, 8 Jan 2020 17:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 YLqDWW4aefBB for <>; Wed, 8 Jan 2020 17:53:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2603F120020 for <>; Wed, 8 Jan 2020 17:53:04 -0800 (PST)
Date: Wed, 08 Jan 2020 17:53:03 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578534783; bh=lR/3rW6kRe/W3zmsDQfec9Y2H4MGJ3sWjIGvpMRIDq8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mOrg+54P+7bgwFUYUjk5o9muFHtVH2hIc6/NEFFiJFEpfql2hf4rRT8giGRrgj29N Cs+bXNsTbDPdxrb6EAx5BmoRp3eGYcvmbomXPDrQXlskU8iecvgvmQMvUijfgsZ9dR OZAH06859UN66H8aBI65i9bEFeJCV285BrPUwZuM=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3326/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Make SNI more clearly mandatory (#3326)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e16877f6f671_47e43fcec70cd96c198752"; 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: Thu, 09 Jan 2020 01:53:07 -0000

martinthomson commented on this pull request.

> @@ -312,11 +317,14 @@ an explicit port.
 ## Connection Establishment {#connection-establishment}
-HTTP/3 relies on QUIC as the underlying transport.  The QUIC version being used
-MUST use TLS version 1.3 or greater as its handshake protocol.  HTTP/3 clients
-MUST indicate the target domain name during the TLS handshake. This may be done
-using the Server Name Indication (SNI) {{!RFC6066}} extension to TLS or using
-some other mechanism.
+HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of other
+QUIC transport versions with HTTP/3 MAY be defined by future specifications.
+QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.
+HTTP/3 clients MUST support a mechanism to indicate the target host to the
+server during the TLS handshake.  Unless an alternative mechanism for indicating
+the target host is used, clients MUST use the Server Name Indication (SNI)
+{{!RFC6066}} extension to TLS if the target host is a DNS name.

Yeah, I don't think that the WebRTC case applies here, though as a general caution it is worth bearing in mind.  ESNI might be modeled as an alternative that is OK on those terms, but if the information is deliberately withheld on the basis of privacy in a specific context, then this requirement could be problematic.  I would expect an update to this document to be necessary in that case.

> "If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) ... extension to TLS unless an alternative mechanism for indicating the server is available"

This says something subtly different logically.  I had the ordered list:

1. if alternative, use that
2. if domain name, use SNI
3. else, don't bother

This says:

1. if domain name,
   a. if alternative, use that
   b. else, use SNI
2. else don't bother

I'm OK with that, but I want to recognize the subtle distinction.  On balance, it's a good distinction because it avoids levying requirements for identification of non-domain names, but I wanted to highlight that to be sure that we all agree that is the intent.

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