Re: HTTPSSVC record draft

[Mark Andrews <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: <[e-mail]>
> > Date: Wed, Jul 3, 2019 at 1:06 PM
> > Subject: New Version Notification for draft-nygren-httpbis-httpssvc-01.txt
> > To: Mike Bishop <[e-mail]>, Erik Nygren <[e-mail]>, Benjamin Schwartz <[e-mail]>
> > 
> > 
> > 
> > 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: [phone]              INTERNET: [e-mail]
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]