Re: [Doh] Talking to my resolver

[nusenu <[e-mail]>]

Martin Thomson wrote:
> It also fails to authenticate any of the information that is
> provided.  

The mechanism in chapter 2 (DoH Servers from HTTPS) is authenticated, right?
(but still vulnerable to downgrade attacks). If we ignore the fact that
the resolver IP has probably been configured over an unsafe protocol in the first place (DHCP).


> Arguably, none of this information can be authenticated
> given its origin, but the number of unauthenticated steps is
> typically limited, but here we have an additional exposure to
> attack.
> 
> It seems like the approach that has been taken with DoT is to try and
> see.  

Those that do (Android 9 for example) don't really authenticate 
the endpoint and use it opportunistically, right?

> But we're all sufficiently scared of HTTP servers that we don't
> feel like that is a responsible thing to do with DoH.  And - more
> reasonably - we realize that having a way to find alternative
> endpoints for a resolver is worth having.  But why not provide a
> mechanism that can do for DoT what this does for DoH? 

I'd like to see that happen as well but I assume that will not be on the DoH WG
since it is outside it's charter?

The idea I had in mind would be to have "DoT Servers from HTTPS"
like section 2 in this draft but without the unauthenticated options
in section 3 and 4.

 
> HTTP also has a convenient mechanism for doing exactly what this
> draft is attempting to do (almost, more later): find an alternative
> service endpoint for the current service, ideally one with better
> properties in some way.  RFC 7838 describes alternative services,
> which are implemented as a header field (here, an EDNS0 option seems
> like it might work).  In that design, a response from the resolver
> contains a list of alternative service endpoints, expressed as a
> tuple of name (and port) and endpoint type (using ALPN).  With some
> DNS-specific tweaks, I don't see why that would be a terrible
> approach here.

How would the DoH URI be authenticated in that case?


> I'd like to have a little more discussion of why we think that
> web sites might want to do their own DNS querying

+1

> FWIW, I'm now unclear on why the draft calls "browsers" out
> specially.  Browsers aren't really special in this context.  You
> might reasonably care about three levels of things: devices (or
> operating systems), applications, and web sites.  The distinction
> between each being decreasing levels of access to information about
> their operating environment.  Applications might not know about their
> DHCP configuration and web sites generally can't directly access a
> DNS resolver directly.

I brought this up as well and Paul mentioned he will address this in the
next version of the draft:
https://mailarchive.ietf.org/arch/msg/doh/bOL0JX0QA-y9qA2G88ngSDSzQAI


> p.s., Happy to talk about how IP address certificates will make this
> difficult to deploy, but let's try to hit the high points first.

It will require the resolver to be on a public IP but letsencrypt
might issue certificates for IP addresses in the future:

"Let’s Encrypt may offer IP address certificates in the future, but as of September 2018 we do not. "
https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082

https://datatracker.ietf.org/doc/draft-ietf-acme-ip/




-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu