Re: [DNSOP] Fwd: HTTPSSVC record draft

[Ben Schwartz <[e-mail]>]

On Tue, Jul 9, 2019 at 12:11 PM Tim Wicinski <[e-mail]> 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.
>

Are they HTTP-based?


>
> I would hope for a solution which would work across all solution spaces -
> not just web browsers.
>
> Tim
> (speaking only as myself)
>
> On Mon, Jul 8, 2019 at 5:20 PM Erik Nygren <[e-mail]> wrote:
>
>> 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
>> <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 <[e-mail]> wrote:
>>
>>> 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:    [e-mail]
>>> Date:   Wed, 3 Jul 2019 14:45:47 -0400
>>> From:   Erik Nygren <[e-mail]>
>>> To:     [e-mail] Group <[e-mail]>, Mike Bishop
>>> <[e-mail]>, Erik Nygren <[e-mail]>, Benjamin
>>> Schwartz <[e-mail]>, Erik Nygren - Work <[e-mail]>
>>>
>>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>