[DNSOP] Fwd: HTTPSSVC record draft

[Ray Bellis <[e-mail]>]

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: 	[e-mail]
Date: 	Wed, 3 Jul 2019 14:45:47 -0400
From: 	Erik Nygren <[e-mail]>
To: 	[e-mail] Group <[e-mail]>, Mike Bishop 
<[e-mail]>, Erik Nygren <[e-mail]>, Benjamin 
Schwartz <[e-mail]>, Erik Nygren - Work <[e-mail]>




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