Re: [Doh] [Ext] draft-ietf-doh-resolver-associated-doh-02 comments

[Paul Hoffman <[e-mail]>]

On Mar 19, 2019, at 1:53 PM, Stephen Farrell <[e-mail]> wrote:
> - Section 2: what about OCSP? are we assuming that the OCSP
> responder is resolved by the precursor system resolver or
> the DoH resolver or both? I don't think it makes a security
> difference (OCSP works or doesn't as usual), but it may be
> a gotcha in terms of establishing the TLS session. Or, are
> we assuming there's no point in OCSP for an IP-address
> cert? (I forget;-)

This is an interesting question. It assumes that the application has no DNS resolver when the HTTPS query is sent, and that getting the associated DoH server is a prerequisite to sending DNS (in this case, to locate the OCSP server).

That was certainly not the intention, given that the application can send DNS queries for the other protocols described. I'll add a note to that effect in the next draft.

> - Section 2: "the normal rules for HTTP" - does that mean
> all re-directs MUST be HTTPS too? And can those URLs use
> DNS names or must they be IP address certs too?

The term "normal HTTP" was used in the DoH spec (RFC 8484), and here "normal rules for HTTP" were assumed to be the same.

> - Sections 3 & 4: the use of special-use domain names here
> seems ickky to me. ("ickky" being a technical terms for "I
> don't like that but can't justify my opinion" :-) I think
> it'd be a pity to see more crap DNS queries emitted from
> browsers though and would love to see something better.

Better suggestions are still heartily welcomed. These are the result of many comments on earlier drafts, but you are not alone in disliking the use of special-use domain names.

> I
> also wonder what'd happen with these queries in a home n/w
> with a never-updated router or with a brand-new flashy
> home router that e.g. has a public DNS name.

Nothing special. If a resolver doesn't understand the SUDN, it will pass it upstream and get an NXDOMAIN answer back.

> (In that
> latter case, I can easily get a cert for the name of my
> home router, but not for it's IP address.)

Certificates are not useful for the protocols in these sections.

> - Section 7, para 1: that's way too one-sided. DoH could
> be less privacy-friendly (than say DoT) due to cookies and
> whatnot.

The sentence explicitly says "communication privacy", not overall privacy, for the very reason you give. I guess that wasn't clear enough. I'll add "However, using a DoH server can also reduce overall privacy because both TLS and HTTPS allow for user identification in ways that plain Do53 does not."

> - Section 8: Why diss. DoT? It's not a competition:-)

For many people, it is. That is, people constantly ask why should DoH even exist if DoT already exists. This helps explain that.

--Paul Hoffman