Subject: [Doh] ICMPv6 Option for DoH

From: "Rayhaan Jaufeerally (IETF)" <[email-masked]>
Date: Tue, 26 Mar 2019 00:07:42 +0100

Dear DoH WG,

I came across your `draft-ietf-doh-resolver-associated-doh` whilst thinking
about how to propagate DoH configuration information to end hosts.

Specifically, I was thinking about proposing an ICMPv6 Router Advertisement
option which would embed this information in an RA message, in a similar
manner to the Provisioning Domain architecture (
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/?include_text=1
).

The information contained in this option could be the URL template, and
current IP address of the resolver, and a lifetime. This would be to
bootstrap the resolution process (i.e. instead of fetching the
/.well-known/doh-servers-associated/ path).

In my opinion two advantages of this approach would be that the
configuration information passing through this channel can be secured using
Secure Neighbor Discovery (as opposed to do53 which is more easily
intercepted). Furthermore, using a domain name to refer to the server means
that end host can refresh the IP address of the server by periodically
looking up the FQDN of the DNS server. This could simplify processing of RA
messages since only a lifetime timer needs to be kept to re-query for the
FQDN (assuming the same FQDN is being distributed by the RA).

Unfortunately, I cannot make it to IETF 104 in Prague this week, but do let
me know if anyone has any opinions on this proposal.

Regards,
Rayhaan

-- 
Rayhaan Jaufeerally -- https://www.rayhaan.ch

NOC contact: +41 078 636 7556 / [email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 10:36:53 +0100

I have been considering many issues on the DoH and DoT protocols, along
with the important use cases (dissidents, network operators, security
issues, clients and servers).

In the interests of advancing the discussion, I have the following
observations, and possible proposal.

I'm raising them here, in advance of the DoH meeting and of the side
meeting, so as to not need to draw pictures or use a lot of words to
describe these ideas, which hopefully will allow more focused discussion if
this comes up in either meeting.

Observation:
DoH uses HTTPS, and as currently specified, re-uses the existing HTTPS port
number, 443.
However, as far as I know, most (or all?) HTTP(s) servers are fully capable
of listing on multiple IP addresses, multiple ports, and doing name-based
virtual hosting. Similarly, browsers are able to access HTTP servers on
non-standard ports, by appending the port number to the server name in the
URI.

Proposal:
Have IANA assign a new port number, for use exclusively for DoH.
NB: I am not suggesting that DoH operate ONLY on the new port, but rather
that DoH operate on BOTH the new and old port numbers.
Also: this presumes that everything supported on the original DoH port,
would be supported on the new DoH port, e.g. including HTTP/3 if/when it
reaches the RFC status.

Rationale:
This is a compromise between those suggesting/requesting/demanding that
browsers use DoT in addition to DoH, with preference of DoT over DoH, and
possibly using inaccessibility on DoT as a way of inferring network policy
prohibiting use of DoH.

The main reasons for wanting DoT to be used are: (1) unique, dedicated port
number; and (2) remove the burden/requirement to handle all the HTTP(S)
encoding, parsing, negotiation, etc., and (3) having to choose between
running a full-blown web server, or re-implementing only the necessary
subset of web server software to support DoH.

Thus, using an additional dedicated port number for DoH, would allow
clients to cooperate with network operators' desire to have a dedicated
port number for Do{HT}, while not having any additional implementation
effort (since the DoH protocol would not be impacted, only the port number
used). In addition, the inferred policy logic would be equally supportable,
whether the first port used was DoT or DoH(new port). Failure to connect
would potentially allow the client to infer that the issue is network
policy preventing access on the port(s) in question.

Dissidents would still have DoH(443) available, possibly without attempting
to use the new port first. The informed user consent issue would still
apply, whether through preferences configuration, or via UI. Also, the
issue of what browsers use as their defaults, including whether/when to
fall back, is a separate issue that needs to be discussed.

I would still encourage browsers to implement DoT, since the incremental
work required is negligible, and since there may be significant push-back
by DNS operators against requiring the HTTP portion of DoH, in order to
offer privacy to DNS customers. Browsers would be able to fall-back to DoT
if no connection could be established on either of the two DoH ports,
rather than having to fall back to plain DNS, or use of a different DNS
service provider.

Brian Dickson
(speaking ONLY for myself)