Re: HTTPSSVC record draft

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 <ianswett@google.com> 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
>
> On Mon, Jul 8, 2019 at 5:12 PM Erik Nygren <erik+ietf@nygren.org> wrote:
>
>> 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 <marka@isc.org> wrote:
>>
>>> 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 <erik+ietf@nygren.org> 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:
>>> >
>>> >       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: <internet-drafts@ietf.org>
>>> > Date: Wed, Jul 3, 2019 at 1:06 PM
>>> > Subject: New Version Notification for
>>> draft-nygren-httpbis-httpssvc-01.txt
>>> > To: Mike Bishop <mbishop@evequefou.be>, Erik Nygren <
>>> erik+ietf@nygren.org>, Benjamin Schwartz <bemasc@google.com>
>>> >
>>> >
>>> >
>>> > 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
>>> >
>>>
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>
>>>