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

Martin Thomson <notifications@github.com> Wed, 08 January 2020 00:29 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833A412010F for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 16:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92q-i51WffBm for <quic-issues@ietfa.amsl.com>; Tue, 7 Jan 2020 16:29:36 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A598120077 for <quic-issues@ietf.org>; Tue, 7 Jan 2020 16:29:36 -0800 (PST)
Received: from github-lowworker-c53a806.ac4-iad.github.net (github-lowworker-c53a806.ac4-iad.github.net [10.52.23.45]) by smtp.github.com (Postfix) with ESMTP id 78369660032 for <quic-issues@ietf.org>; Tue, 7 Jan 2020 16:29:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578443375; bh=A1z4V+Gge12sqMqYAzrRDLq8zPr8E5ll2NGs6aq2Qg8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mEyqUmP/xx5niIXFKeYhirncFWCCkxAiLY8aKt7wTvDtI5tb0ZoKx55rqhMz0zhdu s+yPe9CNq+c590uESR24gZQyGyBAl0wZL9jUhmkq9g4a83nqABP7ssMmA0BGrsft4B PXMp7PUGhsM1pVF8n8L4Qp5kMfG2dmZfTDJvPlrY=
Date: Tue, 07 Jan 2020 16:29:35 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2JGN3JBDMZ3VVXOWF4EJKO7EVBNHHCBE4OS4@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/571836314@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3324@github.com>
References: <quicwg/base-drafts/issues/3324@github.com>
Subject: Re: [quicwg/base-drafts] Confusing SNI recommendation in the HTTP/3 spec (#3324)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e15226f67da2_42723f9dc82cd9681261b2"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LdkKK-Wnuqt5Z4C9f_VBUPKFcs0>
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: Wed, 08 Jan 2020 00:29:38 -0000

Maybe the rule can be concretely:

1. if you have something else/better use that, otherwise
2. if you have a domain name, include SNI, and finally
3. if you don't have a domain name (including IP literals), do whatever.

The HTTP scheme permits a broader range of "host" identifiers than we usually contemplate, so the 3rd option has to catch more than just IP literals.

TLS was always necessarily lax because different applications have different constraints, but the idea was to ensure that for cases where you have the ability to use SNI that you used it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-571836314