Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

[nusenu <[e-mail]>]

A general question before some more comments:

If the application supports the discovery mechanism in this
I-D _and_ has an option where the user can explicitly set
a DoH URI (like current Firefox has), in that case 
the DoH URIs discovered via this protocol MUST NOT override
the user's choice, correct?
(since some of the discovery mechanisms
in the current draft use unauthenticated data).

the text could be something like:

"If the DoH client has a DoH URI configured already, 
it MUST NOT override the DoH URI learned through the discovery
mechanisms in this document."


> 3.  DoH Servers from DNS
> 
>    To find the URI templates for DoH servers associated with a resolver,
>    a browser sends that resolver a query for "resolver-associated-
>    doh.arpa" 

I believe this specific discovery mechanism 
introduces a new attack opportunity that is not there
today.

Imagine a client having statically configured his operating system for Do53
via 8.8.8.8 (DNS options in DHCP are ignored on the client)
and imagine an attacker being in the temporary position between the user
and 8.8.8.8 (i.e. an internet cafe).

Under these circumstances "DoH Servers from DNS" allows an attacker 
to persistently set a victims DoH server URI. 
Which gives the attacker access to the victims DNS traffic and allows him
to feed the DoH client arbitrary responses even after the 
victim is out of his reach (i.e. user left the internet cafe). 
There is also no chance the victim could check
the integrity of TXT records via DNSSEC because they will never be signed.

The same attack vector also applies if the user uses Do53 via 10.0.0.1
and the attacker sits between 10.0.0.1 and 8.8.8.8 (the upstream resolver of 10.0.0.1).

Same attack vector applies to section 4 (Resolver Addresses from DNS).

>    A client MUST re-issue the queries in "DoH Servers from DNS" and
>    "Resolver Addresses from DNS" every time the configured resolver in
>    the operating system changes.

This would break the persistence of the attack but does not help if the user
statically configured his resolver (ignoring DNS options in DHCP) or the internet cafe
is using the same resolver as the victim's home network (i.e. 8.8.8.8).

To avoid introducing this new attack vector and to prevent downgrade
attacks from section 2 to less safe option 3 I would suggest
to stick to the safest option in the current I-D (DoH Servers from HTTPS)
and drop the less safe options or at least add the following 
3 parts to reduce the impact (persistence) of the attack and
to make it clear to implementer and operators that they MUST 
do/provide the option described in section 2 before doing
section 3:

1)
extend: 

> A client MUST re-issue the queries in "DoH Servers from DNS" and
> "Resolver Addresses from DNS" every time the configured resolver in
> the operating system changes 

with:

or whenever the client's IP address changes
(even if the resolver does not change). 

2)
extend:

>    If the array of URI templates returned is empty, that indicates that
>    the resolver does not have any DoH servers associated with it.

with:

>    **DoH clients MUST NOT attempt to find DoH servers via the mechanism 
>    defined in section 3 in that case.**

3)

extend section 8 with something like:
"The mechanism in section 2 is the safest and MUST be attempted first."


You could also consider some downgrade attack protections where the attacker
simply blocks 443 to force the unauthenticated mechanism in section 3.

Such a protection could be implemented via an additional field in the JSON file
by borrowing max-age from HSTS.
https://tools.ietf.org/html/rfc6797#section-6.1.1


>    The returned JSON object [RFC8259] MUST contain a member whose name
>    is "associated-resolvers" and whose value is a JSON array.  The array
>    contains zero or more JSON strings, each of which is a single URI
>    template.


It would be great if the JSON format would specify an optional description
field. The description could then be displayed in the application UI. This would allow
the operators to provide multiple profiles that can be selected by the user.
If multiple URIs are defined the DoH client must use the first one
by default if the user didn't choose one explicitly (if DoH is used by default).

such a JSON file could look like:

{
  "associated-resolvers": [
    {
      "uri": "https://doh.example.com/dns-query",
      "description": "Non-filtering and DNSSEC-validating resolver"
    },
    {
      "uri": "https://doh.example.com/dns-query-filtering",
      "description": "DNSSEC-validating resolver filtering known malware domains"
    }
  ]
}

>> I find these suggested .well-known URLs clearer than
>> "doh-servers-associated".
> 
> I'm generally against this idea for two reasons:
> 
> - No one will see this URL other than software developers and
> operators watching their logs. They will not be visible to users.

It is probably not so important how the url/file is called in the end
but having a speaking name with "dns-over-https-..." in its name
would be clearer than just doh-.. even if only operators have to place
the file on their servers and no end user will ever see that URL.

thanks for working on this!
nusenu

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu