Re: [Tsv-art] Tsvart last call review of draft-ietf-doh-dns-over-https-13

[Patrick McManus <[e-mail]>]

thanks for the review!


On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont <[e-mail]>
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-TCP.pdf).
> Defending
> 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 <[e-mail]>
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 ​[e-mail] 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-assessment-TCP.pdf).
> Defending
> 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
>
>
>