Subject: [Add] draft-schwartz-svcb-dns-01

From: Daniel Migault <[email-masked]>
Date: Wed, 25 Nov 2020 17:09:43 -0500

Hi,

Please find my comments below for draft-schwartz-svcb-dns-01

Yours,
Daniel
                Service Binding Mapping for DNS Servers
                       draft-schwartz-svcb-dns-01
[...]

1.  Introduction

   The SVCB record type [SVCB] provides clients with information about
   how to reach alternative endpoints for a service, which may have
   improved performance or privacy properties.

<mglt>
It is unclear to me if "alternative"
means "various flavors of DNS resolvers"
or if it assumes the previous knowledge
of one flavor of the resolver. I do not
believe the latest is appropriated.

The input of a SVCB query is a FQDN, and
that FQDN is not necessarily related to
a Do53 resolver for example. It could
typically an entry point used to
discover all different flavors of DNS
resolvers. Assuming a previous knowledge
of one resolver seems to preclude some
assumption on the FQDN, which seems
independent from the description of SVCB
fro DNS.
</mglt>

The service is
   identified by a "scheme" indicating the service type, a hostname, and
   optionally other information such as a port number.  A DNS server is
   often identified only by its IP address (e.g. in DHCP), but in some
   contexts it can also be identified by a hostname (e.g.  "NS" records,
   manual resolver configuration).

<mglt>
I like the paragraph, but I believe it
might help the reader to add that DNS
servers can be authoritative or resolver
which are quite common term. I am
wondering however, if there are any
reasons for not mentioning them.

</mglt>

Schwartz                Expires 11 February 2021                [Page 2]

Internet-Draft                SVCB for DNS                   August 2020

   Use of the SVCB record type requires a mapping document for each
   service type, indicating how a client for that service can interpret
   the contents of the SVCB SvcParams.  This document provides the
   mapping for the "dns" service type, allowing DNS servers to offer
   alternative endpoints and transports, including encrypted transports
   like DNS over TLS and DNS over HTTPS.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Name form

   Names are formed using Port-Prefix Naming ([SVCB] Section 2.3).  For
   example, a DNS server with the name "dns1.example.com", listening
   (unusually) on non-default port number 5353, would be represented as
   "_5353._dns.dns1.example.com.".

<mglt>
While this seems conform to the SVCB
spec ;-) I would have envisioned the
port number prefix as designating the
service rather that actual port on which
the service is run. Typically in Do53
would be designated as _53._dns and if
that service is run on port 5353 I would
expected the number being provide by the
port SvcParameter.

One specific reason for doing so is that
the unconventional port cannot be
guessed without previous knowledge.

I believe that some specific convention
should considers that _dns may designate
the DNS service including all flavors.

</mglt>

4.  Applicable existing SvcParamKeys

4.1.  port

   This key is used to indicate the target port for connection.  If
   omitted, the client SHALL use the default port for each transport
   protocol: 853 for DNS over TLS and 443 for DNS over HTTPS.

<mglt>
I have the impression some text is needed to define how the transport is
determined.
I favor that port is being specified in
this field as opposed to in the prefix.
I also believe that the port number
should not be defined at two distinct
places.

It seems that the default values depends
on other SvcParameters - alpn or absence
of it.
</mglt>

   This key is automatically mandatory if present.

<mglt>
I might be missing some context here,
but the latest sentence is a bit hard
for me to understand.

The condition " if present" seems
contradicting the term "mandatory". I
cannot figure out also what
automatically mandatory means.

</mglt>

4.2.  alpn and no-default-alpn

   These keys indicate the set of supported protocols.  The default
   protocol is "dot", indicating support for DNS over TLS [DOT].

   If the protocol set contains any HTTP versions (e.g. "h2", "h3"),
   then the record indicates support for DNS over HTTPS [DOH], and the
   "dohpath" key MUST be present (Section 5.1).  All keys specified for
   use with the HTTPS record are also permissible, and apply to the
   resulting HTTP connection.

<mglt>
I believe the text may specify the
absence of alpn means DNS over UDP. I am
unsure whether no-default-alpn means
that alpn key is omitted or not, but if
that is the case, it does not seem
necessary to introduce its designation.
Instead it might be clear enough to
mention the alpn default value considers
DNS over UDP.

It also worth mentioning that alpn needs
to be parsed before port and potential
dohpath.
</mglt>

   If the protocol set contains protocols with different default ports,
   and no port key is specified, then protocols are contacted separately
   on their default ports.  Note that in this configuration, ALPN
   negotiation does not defend against cross-protocol downgrade attacks.

Schwartz                Expires 11 February 2021                [Page 3]

Internet-Draft                SVCB for DNS                   August 2020

   These keys are automatically mandatory if present.

4.3.  Other applicable SvcParamKeys

   These SvcParamKeys apply to the "dns" scheme without modification:

   *  echconfig

   *  ipv4hint

   *  ipv6hint

<mglt>
not sure we need this section as the
document is limited on the DNS
transport.

I am however wondering if we should
distinguish between authoritative and
resolver.

</mglt>

[...]

7.  Relationship to DNS URIs

   The "dns:" URI scheme [DNSURI] describes a way to represent DNS
   queries as URIs.  This scheme optionally includes an authority,
   comprised of a host and port number (with a default of 53).  DNS URIs
   normally omit the authority, or specify an IP address, but a hostname
   is allowed, in which case it is suitable for use with this mapping.

Schwartz                Expires 11 February 2021                [Page 4]

Internet-Draft                SVCB for DNS                   August 2020

8.  Examples

   *  A resolver at "resolver.example" that supports

      -  DNS over TLS on "resolver.example", port 853 and 8530, with
         "resolver.example" as the Authentication Domain Name,

      -  DNS over HTTPS at "https://resolver.example/dns-query{?dns}",
         and

      -  an experimental protocol on "fooexp.resolver.example:5353":

         $ORIGIN example.
         _dns.resolver 7200 IN SVCB 1 resolver (
           alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} )
         _dns.resolver 7200 IN SVCB 2 resolver (
           port=8530 echconfig=... )
         _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353
           echconfig=... alpn=foo no-default-alpn foo-info=... )

   *  A nameserver at "ns.example" whose service configuration is
      published on a different domain:

      $ORIGIN example.
      _dns.ns 7200 IN SVCB 0 _dns.ns.nic

<mglt>
I am wondering if ther is any room for
searching specifically doh server by
requesting:

_443._dns.resolver 7200 IN SVCB 1 resolver (
           alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} )

If that is not the case, it seems we
should clarify this.
The same case occurs with DoT, Do53.

The advantage would be that it enables
to narrow down the search and prevents
the search of non supported transports.

The downside is that it requires some
synchronization between SVCB RRsets and
when multiple supports are supported by
one client multiple queries may be
performed. It also may require to define
some preference across SVCB RRsets over
multiple domains.

</mglt>

9.  Security Considerations

9.1.  Adversary on the query path

   This section considers an adversary who can add or remove responses
   to the SVCB query.

   Clients MUST authenticate the server to its name during secure
   transport establishment.  This name is the hostname used to construct
   the original SVCB query, and cannot be influenced by the SVCB record
   contents.
<mglt>
I understand that after the SVCB
exchange, the DNS client sets a TLS
session with the DNS server. I think
this is only valid when TLS is
supported and Do53 woudl not fit in this
category.
It sounds to me difficult to have a
requirement that says, when a https
server supports https the session must
be authenticated. I am tempted to say
that the https server should not serve
non secure sessions. On the other hand,
one can also envisioned the case where
a given IP/FQDN is shared by DoH and
Do53, which makes such assumption
difficult.
Unless I am missing something, it sounds
to me the MUST statement is difficult to enforce.

I think it is good to specify what name
must be present in the certificate.
Though what is unclear to me is why the
name should be the one of the query as
opposed as the one in the RDATA.

I understand the text as saying that
connecting to fooexp.resolver.example, the
certificate should have
resolver.example. If that is correct,
and unless I am missing something, I
would be more inclined to authenticate
fooexp.resolver.example.
One case I see is an ISP delegating to a
DNS resolver provider - like akamai. It
should rather let the user authenticate
akamai than the ISP hostname. Other
scenario could ignore the hostname and
use a footprint or the entire
certificate.
Of course this would require DNSSEC.

It seems such recommendation is limited
to the case when DNSSEC is not used and
when the SVCB name is provisioned in a
trusted manner.
If an attacker is likely
to update the SCVB content, he might
potentially have provided the false
entry to initiate the SVCB query, in
which case there may not be any need to
update the SVCB parameters.

I believe the primary recommendation should be
to use DNSSEC and then consider the very
specific use case where DNSSEC cannot be
used with a trusted SVCB entry.
</mglt>

   Accordingly, this draft does not mandate the use of
   DNSSEC.  This draft also does not specify how clients authenticate
   the name (e.g. selection of roots of trust), which might vary
   according to the context.

   Although this adversary cannot alter the authentication name of the
   server, it does have control of the port number and "dohpath" value.
   As a result, the adversary can direct DNS queries for $HOSTNAME to
   any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if
   $HOSTNAME is not actually a DNS server.  If the DNS client uses
   shared TLS or HTTP state, the client could be correctly authenticated
   (e.g. using a TLS client certificate or HTTP cookie).

Schwartz                Expires 11 February 2021                [Page 5]

Internet-Draft                SVCB for DNS                   August 2020

   This behavior creates a number of possible attacks for certain server
   configurations.  For example, if "https://$HOSTNAME/upload" accepts
   any POST request as a file upload, the adversary could forge a SVCB
   record containing "dohpath=/upload", causing the client to upload
   every query, resulting in unexpected storage costs.

   As a mitigation, a client of this SVCB mapping MUST NOT provide
   client authentication for DNS queries, except to servers that it
   specifically knows are not vulnerable to such attacks.  Also, if an
   alternative service endpoint sends an invalid response to a DNS
   query, the client SHOULD NOT send more queries to that endpoint.

<mglt>
The attack is limited to DoH and DoT is
not concerned.

This attack is targeting the https
server, but in general the motivation
for the client to authenticate the
server is to protect its privacy. It
seems this should be added or clarified.
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 30 Nov 2020 14:57:34 -0500

> Please find my comments below for draft-schwartz-svcb-dns-01

Thanks for the detailed review.

Yours,
> believe the latest is appropriated.

This is a general summary of SVCB.  When using SVCB, there is a single
logical "service" that can be accessed via different "endpoints".  I'm not
sure what you mean by "flavor", but SVCB assumes that the service's
behavior does not greatly depend on which endpoint you use to access it.

> independent from the description of SVCB

Sorry, I'm still not understanding, possibly because I do not understand
the idea of a "flavor".  The draft assumes a DNS server (or "service")
identified by a domain name, with Do53 service available via A and AAAA
records for that name (if a Do53 service exists, which seems likely to be
common but is not required).

The service is
> reasons for not mentioning them.

This is a deliberate omission: this draft is concerned only with DNS as a
protocol, not with the types of queries and responses that are encoded.  In
principle, this SVCB mapping can be applied independently of whether the
server is authoritative for any names, or supports recursion.

> expected the number being provide by the

The port SvcParam is also supported, but its meaning is different.  The
port prefix identifies the service.  The port SvcParam provides the
location of the alternative endpoint.

> guessed without previous knowledge.

If the client has not been specifically informed that the service's
identity contains an unconventional port, it will assume the default port
(53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix).
Each SVCB record returned may contain a port SvcParamKey indicating where
to find that alternative service endpoint.

> the DNS service including all flavors.

As above, I don't understand what is meant by a "flavor".

> should not be defined at two distinct

These two port numbers have separate meanings: the prefix is an "input"
identifying the service, and the SvcParam is an "output" that locates the
endpoint.

> on other SvcParameters - alpn or absence

Correct: in this draft, there is no single default value for "port".
Instead, in the absence of a specified port, each transport uses its own
default port.  This enables a single SVCB record to represent both DNS over
TLS on port 853 and DNS over HTTPS on port 443, as in the draft's first
example:

         _dns.resolver 7200 IN SVCB 1 resolver alpn=h2,h3 echconfig=...
dohpath=/dns-query{?dns}

(This example enables DNS over TLS on port 853 implicitly.)

We could change default behavior for "port", but it would likely make
typical usages more verbose.

> automatically mandatory means.

Yes, "automatically mandatory" is a specific term from the SVCB draft:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-7.  I've
added a cross-reference for clarity:
https://github.com/bemasc/svcb-dns/commit/535df722c9404413020af34d3d0e7209e3a206c1

> absence of alpn means DNS over UDP.
>

If the "alpn" key is absent, the default is "dot".

> I am

The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is not
supported".  If the "alpn" key is then omitted, the record is useless/null:
it indicates no supported protocols at the alternative endpoint, so no
client will ever attempt to make use of that record.

> mention the alpn default value considers

This draft does not currently offer any way to describe a DNS over UDP
alternative endpoint.

> to be parsed before port and potential

I expect that a client would parse a record completely before attempting to
make use of it, so I'm not concerned with this dependency.

> document is limited on the DNS

Yes, this is perhaps redundant.  We could instead adjust the wording in the
SVCB draft to indicate that these keys are assumed to be broadly
applicable.  However, I don't think it hurts to remind the reader of other
keys that they can use in this context.

> distinguish between authoritative and

This draft is not intended to be specific to one server role or the other.
This is noted in Section 6.

<mglt>
> the search of non supported transports.

This is an interesting idea, but the SVCB framework does not support this
approach.  With SVCB, the client sends a request that describes a logical
service, and receives an RRSet of alternative endpoints covering all the
service's supported protocols.

> some preference across SVCB RRsets over

Personally, I expect that servers will typically implement only a small
number of protocols (at most ~4), and clients will often support more than
one, so transferring the entire configuration in a single RRSet seems
likely to be more efficient overall than issuing multiple queries.

</mglt>
> supported and Do53 woudl not fit in this

Yes.  This draft does not provide a way to describe a Do53 alternative
endpoint.

> be authenticated.

I'm not sure I understand.  Authenticated transport is a requirement for
HTTPS.

> I am tempted to say

This section is only meant to tell clients to perform SSL certificate
validation in the usual way.

> opposed as the one in the RDATA.

The RDATA is potentially untrusted.  In the absence of DNSSEC, an
intermediary could rewrite the RDATA to contain any name.

> resolver.example.

Correct.

> If that is correct,

Yes.  However, the service provider does not know that the name was
provisioned insecurely, and it does not know that the client is validating
DNSSEC, so it has to include the service name in its certificate.  Since
all service providers will place the service name in the certificate,
clients should check for this name, regardless of whether they validate
DNSSEC.

> used with a trusted SVCB entry.

This draft's approach to authentication is inherited from SVCB, which
similarly does not rely on DNSSEC.  In both cases, I think the current
drafts are taking the best approach.  In many or most of the anticipated
applications, DNSSEC is not widely deployed, and we do not need it in order
to deploy SVCB securely.

> The attack is limited to DoH and DoT is

Correct.

> seems this should be added or clarified.

OK, I've added an explanation of why this is privacy-relevant and
strengthened the recommendation:
https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f