thanks for the review!
On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
* Page 5:
> Using the GET method is friendlier to many HTTP cache
> implementations.
Could the queries really be cached for the POST case?
sometimes. sort of. see 7231 4.3.3
* Page 15:
> It is the choice of a client to either
> perform full DNSSEC validation of answers or to trust the DoH server
> to do DNSSEC validation and inspect the AD (Authentic Data) bit in
> the returned message to determine whether an answer was authentic or
> not.
Relying on the DoH server for DNSsec validation does not seem like a good idea.
You want DNSsec to be end-to-end.
my understanding is that
giving the client the choice between doing DNSSEC validation and
trusting the recursive to do so is standard DNS practice.
* Page 15 (Security Considerations):
DoH essentialy switches from a connection-less transport (UDP) to a
connection-oriented one (TCP).
I
disagree a bit. It adds a third TCP based DNS based approach to the DNS
over TCP and DNS over TLS approaches already standardized so it is not
breaking new ground in that sense.
This means that now the server should take care
of all state-exhaustion attacks against TCP (e.g., take a look at:
https://www.gont.com.ar/papers/tn-03-09-security-assessment- ). DefendingTCP.pdf
against such attacks maybe non-trivial. This should at least be mentioned in
the security considerations.
DoH seeks to use HTTPS
substrate best practices in order to inherit the well known properties
and defenses of HTTPS. The first sentence of the security considerations
tries to say this "Running DNS over HTTPS relies on the security of the
underlying HTTP transport." I don't think it makes sense to have each
foo-over-http consider the baseline considerations separately.
* Page 16:>
> HTTP [RFC7230] is a stateless application-level protocol and
> therefore DoH implementations do not provide stateful ordering
> guarantees between different requests.
Are you meaning that requests that are pipelined could be responded in
different order? Something else?
one of the relevant things
http means when it says it is stateless (which iirc is the first
sentence of 7230) is the requests themselves can also be reordered by
intermediaries or even routed onto different connections.. some may hit
various caches and not even be placed on the connection. sometimes the
'intermediary' is the library or _javascript_ engine you are using - DoH
is meant to be expressable at the semantic layer of bodies and headers.
This particular point was raised in conjunction with dnsop's session
signal draft which requires a stateful DNS transport.. HTTPS is
stateless message based (despite being layered on TCP) and therefore we
want to be clear DoH won't work for building a session layer. (that
draft is coordinated).
* Page 16:
> A DoH server is allowed to answer queries with any valid DNS
> response. For example, a valid DNS response might have the TC
> (truncation) bit set in the DNS header to indicate that the server
> was not able to retrieve a full answer for the query but is providing
> the best answer it could get. A DoH server can reply to queries with
> an HTTP error for queries that it cannot fulfill.
Why should this happen? Why not encode this information in the encoded DNS
response (in wire format)'
I'll let paul answer that - he does it more concisely than I can manage :)
** Editorial comments **
Page 3:
> Two primary uses cases were considered during this protocol's
> development.
s/uses/use/
thanks!
Page 3:
Please introduce and expand de acronym "DoH" the first time you employ it.
ack
Page 7:
> This might mean that the
> DoH client retries the query with the same DoH server, such as
> authorization failures (HTTP status code 401 [RFC7235] Section 3.1).
s/such as/such as for/ ?
thanks
* Page 16:> Note that these deadlocks
> also need to be considered for server that a DoH server might
> redirect to.
s/for server/for servers/ ?
thanks
On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
Reviewer: Fernando Gont
Review result: Almost Ready
Hi, all,
I've reviewed this document as part of the Transport Area Review Team's
(TSVART) ongoing effort to review key IETF documents. These comments were
written primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address any
issues raised. When done at the time of IETF Last Call, the authors should
consider this review together with any other last-call comments they receive.
Please always CC tsv-art@xxxxxxxx if you reply to or forward this review.
Please resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
Document: draft-ietf-doh-dns-over-https-13
Title: DNS Queries over HTTPS (DoH)
Reviewer: Fernando Gont
Review Date: August 11, 2018
Summary:
This document is almost ready, but requires some clarifications and, more
importantly, an analysis of the impact of switching from a connection-less
protocol (UDP) to a connection-oriented protocol (HTTPS/TCP) for DNS resolution.
** Technical comments **
* Page 5:
> Using the GET method is friendlier to many HTTP cache
> implementations.
Could the queries really be cached for the POST case?
* Page 15:
> It is the choice of a client to either
> perform full DNSSEC validation of answers or to trust the DoH server
> to do DNSSEC validation and inspect the AD (Authentic Data) bit in
> the returned message to determine whether an answer was authentic or
> not.
Relying on the DoH server for DNSsec validation does not seem like a good idea.
You want DNSsec to be end-to-end.
* Page 15 (Security Considerations):
DoH essentialy switches from a connection-less transport (UDP) to a
connection-oriented one (TCP). This means that now the server should take care
of all state-exhaustion attacks against TCP (e.g., take a look at:
https://www.gont.com.ar/papers/tn-03-09-security- ). Defendingassessment-TCP.pdf
against such attacks maybe non-trivial. This should at least be mentioned in
the security considerations.
* Page 16:>
> HTTP [RFC7230] is a stateless application-level protocol and
> therefore DoH implementations do not provide stateful ordering
> guarantees between different requests.
Are you meaning that requests that are pipelined could be responded in
different order? Something else?
* Page 16:
> A DoH server is allowed to answer queries with any valid DNS
> response. For example, a valid DNS response might have the TC
> (truncation) bit set in the DNS header to indicate that the server
> was not able to retrieve a full answer for the query but is providing
> the best answer it could get. A DoH server can reply to queries with
> an HTTP error for queries that it cannot fulfill.
Why should this happen? Why not encode this information in the encoded DNS
response (in wire format)'
** Editorial comments **
Page 3:
> Two primary uses cases were considered during this protocol's
> development.
s/uses/use/
Page 3:
Please introduce and expand de acronym "DoH" the first time you employ it.
Page 7:
> This might mean that the
> DoH client retries the query with the same DoH server, such as
> authorization failures (HTTP status code 401 [RFC7235] Section 3.1).
s/such as/such as for/ ?
* Page 16:> Note that these deadlocks
> also need to be considered for server that a DoH server might
> redirect to.
s/for server/for servers/ ?
Thanks!
Fernando
