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

Ryan Hamilton <notifications@github.com> Tue, 07 January 2020 22:26 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6884E1200A3 for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 14:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YMmnaiLWJLb6 for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 14:26:47 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE21120025 for <quic-issues@ietf.org>; Tue, 7 Jan 2020 14:26:47 -0800 (PST)
Received: from github-lowworker-5fb2734.va3-iad.github.net (github-lowworker-5fb2734.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id DB6F76A0A56 for <quic-issues@ietf.org>; Tue, 7 Jan 2020 14:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578436006; bh=gVlExT6e4lwRCVelb699V9pAKKhnMTKkUYidOpZVY6I=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=UlsTXA1v5om2U5PC2V4v6MPDNxfkKKo5e9HHvqRzSJr2kEHiOF4Aey22KUOGOC9NF Djf+k0R+ErfLZHDDTrABO8Ufx14e0rchVLFiU+i/1KnqmRn/2vOdyyLa7cU7uI4Tdk 9fHMU+Z1LtlYaA+prCKRFxC18hfmAGAe/PLddd78=
Date: Tue, 07 Jan 2020 14:26:46 -0800
From: Ryan Hamilton <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3BEJQOPPSEB23BX7F4EI4CNEVBNHHCBE4OS4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3324@github.com>
Subject: [quicwg/base-drafts] Confusing SNI recommendation in the HTTP/3 spec (#3324)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1505a6cc990_28ad3ff5540cd9688085a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/z9yBl8I-BGx9SGjYQD6cWZko0GY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 22:26:49 -0000

In reading PR#3323, I noticed that we have the text (unchanged by that PR):

 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.

I read this as saying that in the absence of "some other mechanism" the SNI extension must be present. But as I read 6066, it prohibits IP literals:

   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

As such, I'm not quite sure how to interpret the HTTP/3 MUST when the browser is requesting a URL with an IP literal as the host of the URL's. I could imagine two interpretations:
1. When HTTP/3 says "target domain name" that implicitly excludes IP literals, so no SN extension is expected.
2. When HTTP/3 says "target domain name" that implicitly includes IP literals, so an SNI extension is expected.
(Or probably more likely, 3. I'm misunderstanding something more deeply)

If 1 is the intended behavior it might be worth some text clarifying that. However, it seems like it would be "good" if QUIC handshakes *always* included the client's understanding of the hostname so I'd love the interpretation to be 2 (though that seems to conflict with 6066 so perhaps that's hard.)


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