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

[Ben Schwartz <[e-mail]>]

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