Re: [DNSOP] Fwd: HTTPSSVC record draft

Mark Andrews <marka@isc.org> Tue, 09 July 2019 21:49 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DFA120020 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 14:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DTqxdZY_etFE for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 14:49:54 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24C612000E for <dnsop@ietf.org>; Tue, 9 Jul 2019 14:49:54 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4E24C3AB002; Tue, 9 Jul 2019 21:49:54 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3720D160048; Tue, 9 Jul 2019 21:49:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 221D4160079; Tue, 9 Jul 2019 21:49:54 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uxkpgJL6vZpd; Tue, 9 Jul 2019 21:49:54 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C4367160048; Tue, 9 Jul 2019 21:49:52 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-E1DE84DD-7E55-4ED1-AC92-EB71FCBE8C86"
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <CADyWQ+EA4e8ye9e8AWomrXko06cnT+izfqmK+fHLWGB5NBveLg@mail.gmail.com>
Date: Wed, 10 Jul 2019 07:49:50 +1000
Cc: Erik Nygren <erik+ietf@nygren.org>, IETF DNSOP WG <dnsop@ietf.org>, Ray Bellis <ray@bellis.me.uk>
Content-Transfer-Encoding: 7bit
Message-Id: <1845D2AE-4FF2-47B2-A01D-274401A23676@isc.org>
References: <CAKC-DJikByP+wX-GoD6ntpUWTbr6ioJzB4i8nGQL4NtPWePL3g@mail.gmail.com> <ae353a56-efe5-ce5d-1786-465fc0195071@bellis.me.uk> <CAKC-DJhaZoC2eNH8kP80Dfe-CnsOnRg6A6XDD7pWhwYdx8x7tA@mail.gmail.com> <CADyWQ+EA4e8ye9e8AWomrXko06cnT+izfqmK+fHLWGB5NBveLg@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Wc3K9Y4CFZ3YpY9UwdIcjoVj7Vk>
Subject: Re: [DNSOP] Fwd: HTTPSSVC record draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 21:49:58 -0000

Which invariable ends up being needed to be split over multiple machines for different protocols.  ANAME can’t do that splitting. 

ANAME if it continues to exist needs rules like MX. It also needs to be explicitly looked for by the application. Add a flag to getaddrinfo() if one wants to make that easier.  The DNS server is the wrong place to do this.
-- 
Mark Andrews

> On 10 Jul 2019, at 02:10, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> 
> Erik
> 
> Speaking as myself and not a chair, I see way too many use cases which are API end points using ANAME like features.  Those
> aren't browser based.
> 
> I would hope for a solution which would work across all solution spaces - not just web browsers. 
> 
> Tim
> (speaking only as myself)
> 
>> On Mon, Jul 8, 2019 at 5:20 PM Erik Nygren <erik+ietf@nygren.org> wrote:
>> Ray, thanks for introducing this to dnsop!  
>> I've published a -03 with some of the feedback received so far:
>>      https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03
>> 
>> For DNSOP folks, and ANAME proponents in-particular, 
>> I/we are especially interested in understanding if this would address
>> enough of the customer use-cases driving ANAME were major
>> browsers to implement support for HTTPSSVC, or would any
>> limitations here cause problems there?
>> 
>> I think the ideal would be for this to simultaneously solve 
>> enough of the ANAME use-cases (to ideally obviate the need for ANAME)
>> and to also solve the other problems that clients are interested in solving
>> (ESNI via DNS, H/3 via DNS, etc) to get this broadly deployed at least 
>> for the "web browser" use-case.
>> 
>> Most significant changes from -01 to -03 based on feedback:    
>>       *  Remove the redundant length fields from the wire format.
>>       *  Define a SvcDomainName of "." for SvcRecordType=1 as being the
>>          HTTPSSVC RRNAME.
>>       * Switch from 302 to 307 redirect for HSTS equivalent.
>> but there also some added examples and other clarifications based on feedback received.
>> 
>> While this is still an individual draft, we have been tracking it here:
>>     https://github.com/MikeBishop/dns-alt-svc
>> but as always, commentary on the IETF lists is generally preferable.
>> 
>>    Erik
>> 
>> 
>> 
>> 
>>> On Mon, Jul 8, 2019 at 5:01 AM Ray Bellis <ray@bellis.me.uk> wrote:
>>> For those not paying attention to the HTTP-bis working group, this DNS 
>>> RR was proposed there last week.
>>> 
>>> It appears to subsume the ALT-SVC proposal and also covers the use case 
>>> I had in mind with my HTTP Record draft (i.e. CNAME at the apex).
>>> 
>>> Given that it has someone from at least major browser vendor supporting 
>>> it there's some hope that this will actually be implemented by them.  It 
>>> therefore seems my draft is probably no longer required.  Hopefully 
>>> ANAME will follow it the same way ;-)
>>> 
>>> Ray
>>> 
>>> -------- Forwarded Message --------
>>> Subject:        HTTPSSVC record draft
>>> Resent-Date:    Wed, 03 Jul 2019 18:46:25 +0000
>>> Resent-From:    ietf-http-wg@w3.org
>>> Date:   Wed, 3 Jul 2019 14:45:47 -0400
>>> From:   Erik Nygren <erik+ietf@nygren.org>
>>> To:     ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>, Mike Bishop 
>>> <mbishop@evequefou.be>, Erik Nygren <erik+ietf@nygren.org>, Benjamin 
>>> Schwartz <bemasc@google.com>, Erik Nygren - Work <nygren@akamai.com>
>>> 
>>> 
>>> 
>>> 
>>> Ben, Mike, and I have submitted the first version of a proposal for an 
>>> "HTTPSSVC" DNS record.
>>> 
>>> TL;DR:  This attempts to address a number of problems (ESNI, QUIC 
>>> bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for 
>>> HTTP, etc) in a holistic manner through a new extensible DNS record, 
>>> rather than in a piecemeal fashion.  It is based on some previous 
>>> proposals such as "Alt-Svc in the DNS" and "Service Bindings" but takes 
>>> into account feedback received in DNSOP and elsewhere.
>>> 
>>> Feedback is most welcome and we're looking forward to discussing with 
>>> people in Montreal.
>>> 
>>> Draft link:
>>> 
>>> https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01
>>> 
>>> 
>>> 
>>>   From the abstract:
>>> 
>>> This document specifies an "HTTPSSVC" DNS resource record type to 
>>> facilitate the lookup of information needed to make connections for 
>>> HTTPS URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin 
>>> hostname to be served from multiple network services, each with 
>>> associated parameters (such as transport protocol and keying material 
>>> for encrypting TLS SNI).  It also provides a solution for the inability 
>>> of the DNS to allow a CNAME to be placed at the apex of a domain name.  
>>> Finally, it provides a way to indicate that the origin supports HTTPS 
>>> without having to resort to redirects, allowing clients to remove HTTP 
>>> from the bootstrapping process.
>>> 
>>> By allowing this information to be bootstrapped in the DNS, it allows 
>>> for clients to learn of alternative services before their first contact 
>>> with the origin.  This arrangement offers potential benefits to both 
>>> performance and privacy.
>>> 
>>> This proposal is inspired by and based on recent DNS usage proposals 
>>> such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to 
>>> have SRV or a functional equivalent implemented for HTTP).  These 
>>> proposals each provide an important function but are potentially 
>>> incompatible with each other, such as when an origin is load-balanced 
>>> across multiple hosting providers (multi-CDN). Furthermore, these each 
>>> add potential cases for adding additional record lookups in-addition to 
>>> AAAA/A lookups.  This design attempts to provide a unified framework 
>>> that encompasses the key functionality of these proposals, as well as 
>>> providing some extensibility for addressing similar future challenges.
>>> 
>>> --
>>> 
>>> Some likely FAQs (with some others listed in an appendix):
>>> 
>>> Q: Why this is HTTP-specific?
>>> A: This is because every protocol has different bootstrap requirements.  
>>> This draft is concerned with improving the efficiency and security of 
>>> bootstrapping HTTPS connections.  This proposal does offer room for 
>>> non-HTTPS protocols, but the nature of DNS requires underscore prefixing 
>>> to support protocol-keyed answers within a single RRTYPE. It's also 
>>> unlikely that a single RR format would be the ideal bootstrap mechanism 
>>> for every protocol, and there's no reason that multiple protocols should 
>>> have to share an RRTYPE.
>>> Q: Why is ESNI addressed directly?
>>> A: This helps make a major motivation of this draft more clear.  
>>> Splitting out those sections to a separate-but-associated "alt-svc 
>>> attribute for ESNI keys" draft might make sense, but keeping it here 
>>> helps work through some of the issues together.
>>> 
>>> Q: Why does this try to address the HSTS case?
>>> A: This is a unique opportunity to fix HTTPS bootstrap and avoid 
>>> providing insecure defaults.  We'd originally proposed a separate 
>>> Alt-Svc attribute to indicate hsts-style behavior, but then realized 
>>> that it would make sense to push on that as the default here.
>>> 
>>> Best, Erik
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop