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
