Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Aug 13, 2018 at 1:16 PM, Paul Hoffman <[e-mail]> wrote:

> Thanks for the thorough review. We have a new PR for the changes below.
>
> --Paul Hoffman
>
> On 13 Aug 2018, at 12:32, Eric Rescorla wrote:
>
> COMMENTS
>> S 1.
>>
>>>
>>>   1.  Introduction
>>>
>>>      This document defines a specific protocol for sending DNS [RFC1035]
>>>      queries and getting DNS responses over HTTP [RFC7540] using https
>>>      URIs (and therefore TLS [RFC5246] security for integrity and
>>>
>>
>> You will need a cite for HTTPS.
>>
>
> We'll copy the {{RFC2818}} reference here as well.
>
> S 1.
>>
>>>
>>>      Two primary uses cases were considered during this protocol's
>>>      development.  They included preventing on-path devices from
>>>      interfering with DNS operations and allowing web applications to
>>>      access DNS information via existing browser APIs in a safe way
>>>      consistent with Cross Origin Resource Sharing (CORS) [CORS].  No
>>>
>>
>> "considered"..."include" is odd. I would probably just make this a
>> bulleted list, but alternately, "They were".
>>
>
> "They were" is good here.
>
> S 4.
>>
>>>
>>>      o  Supporting insecure HTTP
>>>
>>>   4.  Selection of DoH Server
>>>
>>>      Configuration, discovery, and updating of the URI Template [RFC6570]
>>>
>>
>> At this point in the document, it is not clear why I would need a URI
>> template, because you don't explain that till S 5. Perhaps in some
>> overview above.
>>
>
> Saying "URI Templates were used because that's the new way to do things in
> the web world" would be honest, but maybe not that helpful in the document.
> Others might have a better way to say this.
>

Sorry, this isn't an argument about templates but rather "why are templates
relevant here at all".

I think you want to say something like "The DOH client is configured with a
URI template [RFC6570] which describes how to construct the URL to use for
resolution."


> S 4.
>>
>>>      offers an unsolicited response that appears to be a valid answer to
>>> a
>>>      DNS query.  This specification does not extend DNS resolution
>>>      privileges to URIs that are not recognized by the DoH client as
>>>      configured URIs.  Such scenarios may create additional operational,
>>>      tracking, and security hazards that require limitations for safe
>>>      usage.  A future specification may support this use case.
>>>
>>
>> I am having some trouble understanding what you are prohibiting here.
>>
>
> I send an query to https://www.ekrexample.com/ over HTTP/2. During that
> HTTP/2 session, I get a DoH request/response pair from that origin.
> https://www.ekrexample.com/ is not in the list of configured URIs allowed
> for DoH for this client. I MUST NOT do anything with that DoH
> request/response.
>

How would you get a DoH request/response pair from that origin? Via push?


Also, "configured" is an odd term if you are talking about web apps
>>
>
> Even web apps appear to have configuration in them, although usually as
> JavaScript list and object declarations.
>

I don't think this is typically how Web programmers would think of it.



> S 5.1.
>>
>>>      DoH servers MUST implement both the POST and GET methods.
>>>
>>>      When using the POST method the DNS query is included as the message
>>>      body of the HTTP request and the Content-Type request header field
>>>      indicates the media type of the message.  POST-ed requests are
>>>      smaller than their GET equivalents.
>>>
>>
>> Because? I assume b/c no encoding. With that said, it is not obvious
>> that this is true because (as shown below) you have to put content-
>> length and content-type in the POST version, so if you had a smallish
>> request, you might gt more expansion that way,
>>
>
> All DoH responses are at least about 17 bytes long (the 12-byte DNS
> message header plus the shortest possible domain name plus the type and
> class), much more typically at least 40 bytes with typical names and even a
> short answer. Base64 of that will be longer than the content length and
> content type. Normal answers will definitely be longer.
>

Well, it's not b64 of that that matters but rather 1/3 of the base64 of
that, because it's only the expansion that matters.

Back of the envelope: 40 * 1/3 ~= 13, and "application/dns-message" is 23
characters.



> S 5.1.
>>
>>>      The DoH client SHOULD include an HTTP "Accept" request header field
>>>      to indicate what type of content can be understood in response.
>>>      Irrespective of the value of the Accept request header field, the
>>>      client MUST be prepared to process "application/dns-message" (as
>>>      described in Section 7) responses but MAY also process any other
>>> type
>>>      it receives.
>>>
>>
>> Why is this good?
>>
>
> To allow other future types of messages that encode DNS information.
>

When those types of messages are defined, they can update this draft.


> What would I do with like image/jpeg.
>>
>
> Nothing. That's why it is a MAY.
>

This just seems like a confusing, non-interoperable, place holder.


> I tend to think of draft-thomson-postel-was-wrong here.
>>
>
> This should be on a different thread, I believe.
>

I don't think so. We're talking about the wisdom of this design choice.



>>>      In the absence of DNSSEC information, a DoH server can give a client
>>>      invalid data in response to a DNS query.  Section 4 disallows the
>>> use
>>>      of DoH DNS responses that do not originate from configured servers.
>>>      This prohibition does not guarantee protection against invalid data,
>>>      but it does reduce the risk.
>>>
>>
>> Do you want to say something about TSIG (and it maybe not being needed
>> here)
>>
>
> Not really. The WG discussed TSIG and decided it was not needed here.
>

Right, and what I'm saying is that this document should say that it
displaces TSIG.

-Ekr