Re: HTTPSSVC record draft

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