Subject: HTTPSSVC record draft

From: Erik Nygren <[email-masked]>
Date: Wed, 3 Jul 2019 14:45:47 -0400

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

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Jul 3, 2019 at 1:06 PM
Subject: New Version Notification for draft-nygren-httpbis-httpssvc-01.txt
To: Mike Bishop <[email-masked]>, Erik Nygren <[email-masked]>,
Benjamin Schwartz <[email-masked]>

A new version of I-D, draft-nygren-httpbis-httpssvc-01.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-nygren-httpbis-httpssvc
Revision:       01
Title:          HTTPSSVC service location and parameter specification via
the DNS (DNS HTTPSSVC)
Document date:  2019-07-03
Group:          Individual Submission
Pages:          22
URL:
https://www.ietf.org/internet-drafts/draft-nygren-httpbis-httpssvc-01.txt
Status:
https://datatracker.ietf.org/doc/draft-nygren-httpbis-httpssvc/
Htmlized:       https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-nygren-httpbis-httpssvc
Diff:
https://www.ietf.org/rfcdiff?url2=draft-nygren-httpbis-httpssvc-01

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.

   TO BE REMOVED: 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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 3 Jul 2019 22:54:57 +0300

>       https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01

Some quick comments:

- What if SvcDomainName has length different from its length field?
  DNS wire-form names are self-delimiting (DNS message parsing relies
  on this).
- What does it mean for SvcDomainName to be absent in alternative
  service form? I would guess it means "same as RRNAME".
- Why there is length field for SvcFieldValue? Why not let it run to
  the end of record?
- 2 byte length field can encode values up to 65535, not 65536. 
  And the length of SvcFieldValue can not be that big, because
  RRDATA and DNS message length limits (both 65535) would be hit.
- Why 302 redirects instead of 307? 302 is frequently buggy.
- I-D.ietf-tls-tls13 -> RFC8446.
- Is there any envisioned use for chained HTTPSSVC records, except
  for type 0 record pointing to type 1 record?
- The MUST requirement to have only one type 0 record and then
  SHOULD behave non-deterministically if this is violated is pretty
  odd.

-Ilari

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 3 Jul 2019 16:21:59 -0400

>   DNS wire-form names are self-delimiting (DNS message parsing relies

Thanks for the review!  The serialization format can definitely be
improved; we want to make it easy to implement and consistent with typical
DNS practices.

The current rationale for the length field is that we need some way of
distinguishing the empty name (i.e. "", meaning "absent") from a name
consisting of an empty label (i.e. ".").  I agree; there's probably a more
intuitive way to represent that.  Suggestions welcome.

>   service form? I would guess it means "same as RRNAME".

Sort of.  Alt-Svc has a concept of "uri-host omitted", in which case the
connection proceeds to the same host.  I think the net effect is the same.

I agree, this seems like something the draft should clarify.  We also need
to figure out what the text representation is.

>   RRDATA and DNS message length limits (both 65535) would be hit.

Suggestions welcome.

> - Why 302 redirects instead of 307? 302 is frequently buggy.

You're right, 307 is probably closer to what we mean.

>   for type 0 record pointing to type 1 record?

You can also have longer chains, (0 -> 0 -> 1), but type 1 does not chain
further.

>   SHOULD behave non-deterministically if this is violated is pretty

Agreed, we can improve that recommendation.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 5 Jul 2019 13:18:52 +1000

> On 4 Jul 2019, at 6:21 am, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jul 3, 2019 at 3:58 PM Ilari Liusvaara <[email-masked]> wrote:
> Thanks for the review!  The serialization format can definitely be improved; we want to make it easy to implement and consistent with typical DNS practices.
> 
> The current rationale for the length field is that we need some way of distinguishing the empty name (i.e. "", meaning "absent") from a name consisting of an empty label (i.e. ".").  I agree; there's probably a more intuitive way to represent that.  Suggestions welcome.]

Why not have “." mean “same host”?  “.” isn’t otherwise a sane value for type 2.
No service can be indicated by '1 0 . “”’.

> Sort of.  Alt-Svc has a concept of "uri-host omitted", in which case the connection proceeds to the same host.  I think the net effect is the same.
> 
> I agree, this seems like something the draft should clarify.  We also need to figure out what the text representation is.
>  
> You can also have longer chains, (0 -> 0 -> 1), but type 1 does not chain further.
>  

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 5 Jul 2019 16:52:48 +1000

A private type implementation is here for BIND.

https://gitlab.isc.org/isc-projects/bind9/merge_requests/2135

Mark

> On 4 Jul 2019, at 4:45 am, Erik Nygren <[email-masked]> wrote:
> 
> 
> 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:
> 
> 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.
> 
> --
> 
> 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.
>  
> 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.
> 
> 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
> 
> 
> 
> To: Mike Bishop <[email-masked]>, Erik Nygren <[email-masked]>, Benjamin Schwartz <[email-masked]>
> 
> 
> 
> Title:          HTTPSSVC service location and parameter specification via the DNS (DNS HTTPSSVC)
> URL:            https://www.ietf.org/internet-drafts/draft-nygren-httpbis-httpssvc-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nygren-httpbis-httpssvc/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nygren-httpbis-httpssvc
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nygren-httpbis-httpssvc-01
> 
> Abstract:

---

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

I've published a -03 for this draft:

    https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03

Most significant changes 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.

That's great to already see a bind9 prototype implementation!
(Does it already associate Additional records from the SvcDomainName
for recursive responses when that was already in-cache?  I'm curious to see
if that is trivial or not to add in existing code bases.)
Reading through the implementation made it quite clear how desirable it was
to remove the redundancy from the wire format.

    Erik

On Fri, Jul 5, 2019 at 2:52 AM Mark Andrews <[email-masked]> wrote:

> 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
> > 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.
> >
> > 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
> >
> >
> >
> > To: Mike Bishop <[email-masked]>, Erik Nygren <
> [email-masked]>, Benjamin Schwartz <[email-masked]>
> >
> >
> >

---

From: Ian Swett <[email-masked]>
Date: Mon, 8 Jul 2019 22:43:44 -0400

Thanks for the updates, this is a very exciting proposal that could greatly
advance HTTPS, QUIC, encrypted SNI, and likely other future innovations.

Is this going to be presented in any other working groups?(ie: dnsop?)  I'd
be interested in their feedback as well.

Thanks, Ian

On Mon, Jul 8, 2019 at 5:12 PM Erik Nygren <[email-masked]> wrote:

>> > 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.
>> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 9 Jul 2019 16:21:22 +1000

Introductory Example: The example record

example.com.      2H  IN HTTPSSVC 0 0 svc.example.net.

does not match the description of the record (missing last field). It should be:

example.com.      7200  IN HTTPSSVC 0 0 svc.example.net. “”

Similarly in 2.4.  HTTPSSVC records: alias form

Also don’t use 2H for the TTL.  While some servers will accept it, it is not RFC compliant.

Unless these is a real reason for the record to be class agnostic please specify that
it is class IN specific.

Mark

> On 9 Jul 2019, at 7:08 am, Erik Nygren <[email-masked]> wrote:
> 
> but there also some added examples and other clarifications based on feedback received.
>

---

From: Erik Nygren <[email-masked]>
Date: Tue, 9 Jul 2019 08:30:19 -0400

Yes, I've sent mail to both the dnsop and tls WG mailing lists, and I have
requested agenda time from both.

So far the response seems to have been very positive from the DNSOP WG,
with a PR for prototype implementation
already in BIND.  Many DNSOP folks have been wanting HTTP(S) to do
something SRV-like for many
years.  There is a draft called "ANAME" for handling zone apex cname
equivalents, almost entirely
for web "http(s)://example.com" onboarding to CDN use-cases, but it
considered to be a hack
that adds lots of complexity.   I perceive strong interest in something
HTTPSSVC-like if browsers are likely
to implement it and if it allows ANAME to be abandoned.  (Hence why
SvcRecordType=0 is included.)

      Erik

On Mon, Jul 8, 2019 at 10:43 PM Ian Swett <[email-masked]> wrote:

> Thanks for the updates, this is a very exciting proposal that could
> greatly advance HTTPS, QUIC, encrypted SNI, and likely other future
> innovations.
>
> Is this going to be presented in any other working groups?(ie: dnsop?)
> I'd be interested in their feedback as well.
>
> Thanks, Ian
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Jul 2019 09:49:21 -0400

> example.com.      7200  IN HTTPSSVC 0 0 svc.example.net. “”

I think the idea was to omit the SvcFieldValue field from the text
representation in mode 0, where it's unused/disallowed.  Do you think
that's too inconvenient for zone file parsing code? To me, it seems more
natural for humans.

---

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

Well parsing is easier if it is not omitted. It a matter of conditionally expecting  end-of-line or not at that point. 

If it is to be omitted it needs to be documented as being optional in the presentation format.  Remember the presentation format is also a interchange format.  The parser needs to know if it should error out or not.  Different implementations should produce the same presentation format from the same wire input. 

-- 
Mark Andrews

> On 9 Jul 2019, at 23:49, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> I think the idea was to omit the SvcFieldValue field from the text representation in mode 0, where it's unused/disallowed.  Do you think that's too inconvenient for zone file parsing code? To me, it seems more natural for humans.