Re: [Doh] [Ext] Re: Authentication in draft-ietf-doh-resolver-associated-doh-03.txt

[Paul Hoffman <[e-mail]>]

> On Mar 25, 2019, at 5:10 PM, Ben Schwartz <[e-mail]> wrote:
> 
> On Mon, Mar 25, 2019 at 7:37 AM Paul Hoffman <[e-mail] <mailto:[e-mail]>> wrote:
> On Mar 25, 2019, at 12:01 PM, Stéphane Bortzmeyer <[e-mail] <mailto:[e-mail]>> wrote:
> > Otherwise, even after reading the whole thread "Reviewing
> > Resolver-Associated DOH", I don't understand why https is required in
> > section 2. We don't require DNSSEC in section 3, so why having
> > stronger requirments for HTTP? Since having certificates for IP
> > addresses will be difficult in practice, why not just accepting http
> > as well as https? (Or, <horror>https without cert. checking</horror>.)
> 
> The reason I didn't drop down to http: is that doing so evokes the <horror> response, even though you are quite correct that the other two methods given in this document do not offer any authentication. So, let me ask the WG:
> 
> Would this document be better off with all three methods being equally unauthenticated? Doing so would remove the "but you can't get IP address certificates!" argument that keeps coming up (even though that is overstated). Doing so would simplify the security considerations by making all three protocols have the same obvious weakness.
> 
> An alternative is to have two URI, one with https: and one with http:, and explain that trying the first might be a good idea but to fall back to the second if authentication fails.
> 
> Thoughts?
> 
> Given that the protocol is called "DNS over HTTPS", running it over unencrypted HTTP seems like a contradiction.  It also complicates any security status indication by introducing a mode that no longer offers any confidentiality benefit over standard DNS.

This may be a misunderstanding. The protocol in section 2 is not running DoH, it is for finding a DoH server, in this case, asking for data from a .well-known location. We can choose whatever protocol we want for that; in Section 3, we use DNS.

> Apart from security issues, insecure HTTP is generally restricted to HTTP/1.1.  DoH implementations are strongly encouraged to use HTTP/2, because HTTP/1.1 requires in-order responses.  Running DoH over HTTP/1.1 increases the likelihood of performance problems.

Again, this is not about running DoH.