Re: [Add] New Version Notification for draft-schwartz-svcb-dns-00.txt

[Ben Schwartz <[e-mail]>]

On Mon, Aug 10, 2020 at 11:53 AM Eric Orth <ericorth=
[e-mail]> wrote:

> Clarification question: Is the draft intended for finding alternate DNS
> servers given a query identifying one DNS server?
>

Pretty much, yeah.

Or is it intended as a generalization of the proposals for finding a
> designated DNS server given something like a webpage? Or both or more?
>
> My reading of the draft was that it was targeting just the first, but from
> your response and considering the three drafts referenced in your original
> email, I'm thinking I may have read the intent too narrowly.
>

This is intended as a reusable component for converting "domain name of a
DNS server" into "instructions for contacting that server over an encrypted
transport".  How you learned that domain name, and what you use it for, are
outside the scope of this draft.  My hope is that this component allows
various other proposals to focus on those questions, and to share at least
the syntax of the encrypted transport parameters for different use cases.

It seems like the emphasis on "dns://" URIs was a source of some confusion,
so I've rephrased the text to avoid that dependency.

On Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> On Fri, Aug 7, 2020 at 5:11 PM Eric Orth <ericorth=
>> [e-mail]> wrote:
>>
>>> I like the idea overall, but can you further explain the decision to use
>>> dns: URIs to describe DNS servers?
>>>
>>
>> I wouldn't say that's what's happening here..
>>
>> The SVCB/HTTPS record describes a way to perform connection establishment
>> when attempting to retrieve a resource by its URI..  (Use of a URI with
>> SVCB is recommended but not required.)  The SVCB draft only defines a
>> mapping for "http://" and "https://" URIs; this draft provides the
>> mapping for "dns://".
>>
>> For both "https://" and "dns://" URIs, SVCB serves the same function:
>> the URI provides an authority, and SVCB provides some information on how to
>> enhance your connection to that authority, in pursuit of the indicated
>> resource.  Ultimately, the client must want to access some resource (i.e.
>> an HTTP resource or a DNS record, indicated by the URI's path in both
>> cases), or there's no need to connect to the authority at all.
>>
>> In truth, I don't think the "dns: URI" part is really important here;
>> it's mostly just a nice conceptual framework for the draft.  The real
>> question is: if we distribute information in this form, will it work well
>> as a component of the systems we're trying to build?
>>
>> Seems a bit funky since that URI scheme is designed for DNS data, not a
>>> DNS server.  What we want here seems to match more with just the optional
>>> "authority" section of a dns: URI.
>>>
>>
>> Yes; this is the SVCB design generally.  Note that the "authority"
>> section is also optional in "https" URIs.
>>
>> Do we need a new URI scheme for DNS servers? Wasn't there a recent
>>> proposal for that?
>>>
>>
>> I believe those proposals are principally inspired by DNS Stamps
>> https://dnscrypt.info/stamps-specifications. With SVCB, the URI
>> (normally) identifies the authority by name, and the protocol is negotiated
>> at connection time.  With DNS Stamps, all protocol and connection
>> parameters are encoded into the URI itself.
>>
>> I think the SVCB approach is more suitable for our purposes, because it
>> separates the simple, important question (who am I sending queries to?)
>> from the complicated, boring question (how do I perform connection
>> establishment?).  This is similar to HTTPS: I wouldn't want to encode QUIC
>> vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get
>> out of sync or distract from the important question (who is the authority?).
>>
>> On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz <bemasc=
>>> [e-mail]> wrote:
>>>
>>>> Moving DPRIVE and DNSOP to BCC to avoid cross-posting.
>>>>
>>>> On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz <[e-mail]
>>>> <bemasc@google..com>> wrote:
>>>>
>>>>> Hi ADD and DPRIVE,
>>>>>
>>>>> I've noticed three recent drafts that propose to use the SVCB format:
>>>>> draft-mglt-add-rdp, draft-tapril-ns2, and
>>>>> draft-pauly-add-resolver-discovery.  These drafts, across multiple
>>>>> working groups, consider distinct use cases and architectures, but they all
>>>>> propose using SVCB (in very different ways) to convey information about a
>>>>> DNS server that supports encrypted transport.
>>>>>
>>>>> In the interest of harmonizing these proposals, creating a solid
>>>>> foundation, and separating concerns, I've written a short draft that
>>>>> specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address
>>>>> any specific use case.
>>>>>
>>>>> I hope this draft can enable each of these proposals to focus more on
>>>>> their goals, and worry less about the SVCB encoding.  (It also serves as an
>>>>> interesting test of the SVCB design.)
>>>>>
>>>>> Please review,
>>>>> Ben Schwartz
>>>>>
>>>>> *SVCB is based on URIs like https://, so for a DNS mapping we start
>>>>> with dns:// URIs.
>>>>>
>>>>> ---------- Forwarded message ---------
>>>>> From: <[e-mail]>
>>>>> Date: Tue, Aug 4, 2020 at 1:38 PM
>>>>> Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt
>>>>> To: Benjamin Schwartz <[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>> A new version of I-D, draft-schwartz-svcb-dns-00.txt
>>>>> has been successfully submitted by Benjamin Schwartz and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:           draft-schwartz-svcb-dns
>>>>> Revision:       00
>>>>> Title:          Service Binding Mapping for DNS URIs
>>>>> Document date:  2020-08-04
>>>>> Group:          Individual Submission
>>>>> Pages:          8
>>>>> URL:
>>>>> https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt
>>>>> Status:
>>>>> https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
>>>>> Htmlized:       https://tools.ietf.org/html/draft-schwartz-svcb-dns-00
>>>>> Htmlized:
>>>>> https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns
>>>>>
>>>>>
>>>>> Abstract:
>>>>>    The SVCB DNS record type expresses a bound collection of endpoint
>>>>>    metadata, for use when establishing a connection to a named service.
>>>>>    DNS itself can be such a service, when the server is identified by a
>>>>>    hostname in a "dns:" URI.  This document provides the SVCB mapping
>>>>>    for name-based DNS URIs, allowing DNS servers to indicate support
>>>>> for
>>>>>    new transport protocols.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> --
>>>> Add mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/add
>>>>
>>> --
>> Add mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
>>
>