Subject: [DNSOP] Fwd: HTTPSSVC record draft

From: Ray Bellis <[email-masked]>
Date: Mon, 8 Jul 2019 10:01:01 +0100

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

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

---

From: Erik Nygren <[email-masked]>
Date: Mon, 8 Jul 2019 17:17:39 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 8 Jul 2019 22:26:49 +0100

> limitations here cause problems there?

I'm personally not aware of any specific use-cases for ANAME that aren't 
  "I want to use my CDN's hostname alias but CNAME's rules prevent it".

That's not to say there aren't any, but if there are, I don't know what 
they are.

kind regards,

Ray

---

From: Brian Dickson <[email-masked]>
Date: Mon, 8 Jul 2019 15:39:54 -0700

Hi, Erik,

One minor issue is that wherever CNAME is referenced, you probably want to
also include a reference to DNAME, including any implied or explicit
chaining of CNAMEs (which could be sequences of CNAME and/or DNAME modulo
their respective behavior.)

It might be a little clearer if the list of alt-svc values (h2, h3, etc)
that can occur were to be listed in the document. In particular, the
association between h3 and QUIC is inferred but not explicitly called out
(at least not that I noticed.)

You might also want to explain the motivation for keeping the FQDN separate
from the alt-svc parameters (to make it trivial to parse, and thus to do
DNS substitutions like CNAME/DNAME). It is there, just not as up-front as
it could be.

Otherwise, I think many of us would very much love to see this implemented,
as much of ANAME is fundamentally incapable of meeting the intended goals,
which this does very nicely.

Brian

---

From: Erik Nygren <[email-masked]>
Date: Mon, 8 Jul 2019 21:30:00 -0400

Thanks for the feedback.  I'll add the DNAME clarification in the next
version,
as well as better explain the FQDN separation motivation.

The alt-svc ALPN values come from rfc7838 (Alt-Svc) and rfc7301 (ALPN).
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

(The "h3" = HTTP/3 over QUIC is not yet in the registry as it is
still-in-progress.  It was actually "hq" initially for Google QUIC.
See https://tools.ietf.org/html/draft-ietf-quic-http-20#section-2.1 for
some details from the active QUIC draft.)

       Erik

On Mon, Jul 8, 2019 at 6:40 PM Brian Dickson <[email-masked]>
wrote:

> You might also want to explain the motivation for keeping the FQDN
> separate from the alt-svc parameters (to make it trivial to parse, and thus
> to do DNS substitutions like CNAME/DNAME). It is there, just not as
> up-front as it could be.
>
> Otherwise, I think many of us would very much love to see this
> implemented, as much of ANAME is fundamentally incapable of meeting the
> intended goals, which this does very nicely.
>
> Brian
>

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 9 Jul 2019 12:10:19 -0400

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)

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Jul 2019 12:32:05 -0400

> API end points using ANAME like features.  Those

Are they HTTP-based?

>> <https://github..com/MikeBishop/dns-alt-svc>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 07:49:50 +1000

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 <[email-masked]> 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
>> but there also some added examples and other clarifications based on feedback received.
>>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jul 2019 00:11:52 +0000

On Tuesday, 9 July 2019 21:49:50 UTC Mark Andrews wrote:
> 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.

+1.

everything other than HTTPS can just use SRV.

ANAME is (should be) toast(ed).

-- 
Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jul 2019 17:35:35 -0700

> ANAME is (should be) toast(ed).

Didn't we get to this point by acknowledging that there was a gap
between now and the glorious future where SRV and unnamed alternatives
for HTTPS, and that the gap was already being filled by multiple,
different, ANAME-looking things?

The point of ANAME was to give us some multi-provider/Interop options
while the trucks roll, I thought. They are not fast trucks. It has
taken 23 years to get from RFC 2052 to here.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 9 Jul 2019 17:44:34 -0700

> different, ANAME-looking things?

not i.

SRV was good enough for HTTP. it was designed after HTTP, for HTTP. the 
reason it wasn't deployed for HTTP has nothing to do with the things 
that make HTTPSSVC necessary for HTTPS. (we would still need HTTPSSVC 
for HTTPS even if HTTP had adopted SRV.)

> taken 23 years to get from RFC 2052 to here.

the web browsing community has very fast trucks. what was a concern for 
the older, larger application-independent "Internet" is not for this. if 
IETF and W3C agree that HTTPSSVC is the way forward, it'll be used for 
50% or more of all web transactions within a year, and 90% within five 
years.

-- 
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 9 Jul 2019 20:52:39 -0400

Will AWS Support this?

That seems to be all I see deployed now

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 23 Jul 2019 17:04:43 +0200

I was too late to join the virtual queue in the dnsop meeting (fighting
with the Meetecho UI), so I'll send a mail to the list:

Slide 5 of the presentation (Alias form) basically covers the ANAME
case, but still relies on the client to chase the target.

The ANAME record is flexible where the target lookup is done (and can be
done at multiple places) at the cost of more complexity.  That
complexity is needed because we cannot assume that the clients will
chase the targets.

But as soon as clients start querying for ANAME (and not address
records) meaning it will chase the target itself, the DNS server
actually does not have to do a target lookup anymore.

Then putting these records in your zone would trigger the same behavior.

example.com.  7200  IN  ANAME    svc.example.net.
example.com.  7200  IN  HTTPSSVC 0 0 svc.example.net.

It almost feels like we could reuse the HTTPSSVC record and allow for
target lookups at the DNS server (MAY do target lookup) if an address
query comes in and a HTTPSSVC record is on the same name.

But then perhaps a more generic name for the RRtype is needed ;)

Best regards,

Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Jul 2019 11:51:39 -0700

At Tue, 23 Jul 2019 17:04:43 +0200,

> actually does not have to do a target lookup anymore.

True, but my understanding is that the key difference is that the web
browser community (at least some big players of it) is willing to
support HTTPSSVC, thereby already overcoming the most difficult part
of the chicken-and-egg problem: how to deploy it in the client side.
I actually don't fully understand how HTTPSSVC has got the support
while ANAME hasn't though (perhaps because of the incentive of other
HTTPSSVC features like the alternative service form?).

Once a sufficient number of clients support it, the authoritative side
will have the incentive of deploying HTTPSSVC, and if it's
sufficiently deployed in the authoritative side, too, then we can
eventually hope to deprecate the practice of CNAME at apex.

Right now, I'm not sure how we can expect this to happen for ANAME
(except by waiting for perhaps several decades, until almost all
recursive servers natively support ANAME).

--
JINMEI, Tatuya

---

From: Erik Nygren <[email-masked]>
Date: Fri, 26 Jul 2019 14:58:30 -0400

The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing
function here for clients.  They need to do something new here to address
that, and if that requires an additional lookup then there is opportunity
if other problems can be solved at the same time as long as we don't slow
down ESNI deployment or hurt performance over an ESNI-specific solution.

    Erik

---

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Jul 2019 17:32:36 -0400

Erik,

In that case you should take a hard look at caching. The ESNI lookup needs to retrieve the name and the SNI key of the published server. It will remain valid as long as the key or the relationship between published and private does not change. If it is cached, the only required real time lookup is for the current address of the published server, which arguably may change more often than the ESNI data. So with proper caching, all that can be optimized.

-- Christian Huitema 

> On Jul 26, 2019, at 2:58 PM, Erik Nygren <[email-masked]> wrote:
> 
> The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing function here for clients.  They need to do something new here to address that, and if that requires an additional lookup then there is opportunity if other problems can be solved at the same time as long as we don't slow down ESNI deployment or hurt performance over an ESNI-specific solution.
> 
>     Erik
> 
>