Re: [DNSOP] Fwd: HTTPSSVC record draft

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
>