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+i...@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 <r...@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...@w3.org >> Date: Wed, 3 Jul 2019 14:45:47 -0400 >> From: Erik Nygren <erik+i...@nygren.org> >> To: ietf-http...@w3.org Group <ietf-http...@w3.org>, Mike Bishop >> <mbis...@evequefou.be>, Erik Nygren <erik+i...@nygren.org>, Benjamin >> Schwartz <bem...@google.com>, Erik Nygren - Work <nyg...@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
