Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Ben Schwartz <[e-mail]>]

On Tue, Sep 24, 2019 at 10:23 AM Bob Harold <[e-mail]> wrote:

>
> On Tue, Sep 24, 2019 at 9:18 AM Erik Nygren <[e-mail]> wrote:
>
>> Following discussions around the "HTTPSSVC" record proposal in Montreal
>> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
>> "draft-nygren-httpbis-httpssvc-03".  The new version is
>> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
>> feedback from the WG discussions, as well as feedback from discussions with
>> the TLS WG (as we'd like to see this replace the need for a separate ESNI
>> record).
>>
>> In particular, it generalizes the record into a new "SVCB" record which
>> doesn't have any protocol-specific semantics.  It also defines an
>> "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
>> parameter registry) and which defines the HTTP(S)-specific semantics such
>> as bindings to Alt-Svc.  Other protocols can either define bindings
>> directly to SVCB or can define their own RR Type (which should only ever be
>> needed if there is a need to use the record at a zone apex).
>>
>> We'd like to see this adopted by the DNSOP WG.  Until then, issues and
>> PRs can go against:  https://github.com/MikeBishop/dns-alt-svc
>>
>> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
>>
>> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of
>> the HTTPS-specific functionality and text to its own portion of the
>> document).
>> * Elimination of the SvcRecordType field (and making the SvcRecordType
>> implicit)
>> * Changing the wire format of parameters from being in Alt-Svc text
>> format to a more general binary key/value pair format (with a mapping to
>> Alt-Svc for HTTPSSVC).
>> * Adding optional "ipv4hint" and "ipv6hint" parameters.
>> * Quite a few cleanups and clarifications based on input (and we
>> undoubtedly have more left to go)
>>
>> This retains support for all of the use-cases that the previous HTTPSSVC
>> record had (such as for covering the ANAME / CNAME-at-the-zone-apex
>> use-case).
>>
>> Feedback is most welcome.  If the TLS WG is going to use this instead of
>> a separate ESNI record, there is a desire to make progress on this fairy
>> quickly.
>>
>>        Erik
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Mon, Sep 23, 2019 at 7:01 PM
>> Subject: New Version Notification for
>> draft-nygren-dnsop-svcb-httpssvc-00.txt
>> To: Mike Bishop <[e-mail]>, Erik Nygren <[e-mail]>,
>> Benjamin Schwartz <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
>> has been successfully submitted by Benjamin Schwartz and posted to the
>> IETF repository.
>>
>> Name:           draft-nygren-dnsop-svcb-httpssvc
>> Revision:       00
>> Title:          Service binding and parameter specification via the DNS
>> (DNS SVCB and HTTPSSVC)
>> Document date:  2019-09-22
>> Group:          Individual Submission
>> Pages:          33
>> URL:
>> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
>> Htmlized:
>> https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc
>>
>>
>> Abstract:
>>    This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
>>    types to facilitate the lookup of information needed to make
>>    connections for origin resources, such as for HTTPS URLs.  SVCB
>>    records allow an origin to be served from multiple network locations,
>>    each with associated parameters (such as transport protocol
>>    configuration and keying material for encrypting TLS SNI).  They also
>>    enable aliasing of apex domains, which is not possible with CNAME.
>>    The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP
>>    origins.  By providing more information to the client before it
>>    attempts to establish a connection, these records offer 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.
>>
>>    TO BE REMOVED: The specific name for this RR type is an open topic
>>    for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
>>    they are easy to replace.  Other names might include "B", "SRV2",
>>    "SVCHTTPS", "HTTPS", and "ALTSVC".
>>
>
> Looks good to me, hope it gets used!
>
> Several places have text like:
>
> 4. DNS Server Behavior
> 2.
> "If at least one record is in AliasForm, ignore all other SVCB records in
> the RRSet."
>
> While the records must be 'ignored', it might be noted that they must
> still be included in the DNS response, if DNSSEC is in use, so that the
> signatures work, I think?
>

True.  I've added this to our tracker:
https://github.com/MikeBishop/dns-alt-svc/issues/55


>
> And my opinion - it should encourage use of DNSSEC.
>
> --
> Bob Harold
>
>