[Doh] more generally on resolver-associated-doh.arpa and resolver-associated-doh.arpa

[Joe Abley <[e-mail]>]

Hi again,

I think my concerns about the "DoH Servers from DNS" mechanism  are wider than those about the blackhole suggestion that I mentioned earlier.

The  "DoH Servers from DNS" mechanism in general involves the retrieval of security-critical information for an end-user's application environment from the DNS in a way that necessarily precludes integrity protection by DNSSEC. A polluted cache, a compromised upstream forwarder or resolver, a man in the middle or just the accidental inheritance of a non-malicious upstream policy can divert all end-user resolver traffic to an unexpected location where the response policy is unknown.\

This is worse than DNSChanger or attacks on local DHCP infrastructure to divert resolver traffic since it has the potential to affect larger communities of end-users without the hurdle of local network or end-host compromise.

Any network that doesn't provision these domains on their local resolvers is hence vulnerable. If successful the impact of such an attack would be difficult to assess by the network operator since of course the query traffic is at that point obscured, being carried as DoH.

Architecturally, I think this mechanism is vulnerable by default, which is a poor security posture. It's a challenge to detect the attack and it's also challenging to defend against (e.g. in the case that an end-user doesn't start the discovery from a local resolver).


Joe

On 26 Mar 2019, at 12:17, Joe Abley <[e-mail]> wrote:

> Hi all,
> 
> There was a suggestion at the microphone this morning in the Grand Ballroom that the resolver-associated-doh.arpa and resolver-associated-doh.arpa domains be "blackholed". The draft currently specifies that these MUST NOT be delegated from ARPA.
> 
> The microphone queue was already cut off before I could ask more about what this means, but I think it's worth reminding the wg what blackhole generally means in this context of DNS names in and near ARPA, and how it can be implemented, since I think there is a security concern.
> 
> RFC 7534 provides two mechanisms to blackhole DNS traffic: one uses DNAME (see RFC 7535) and the other uses a zone cut. The DNAME approach is technically compatible with the MUST NOT in the draft (since it's technically not a delegation but rather a redirection) but the direct delegation mechanism is not.
> 
> In both cases, however, blackholing these domains would point their DNS resolution away from the authoritative servers that serve ARPA towards a loosely-coordinated set of AS112 servers.
> 
> Anybody can operate an AS112 server; in fact, operators have in the past been actively encouraged to operate AS112 servers without any requirement for coordination. This has been considered a reasonable approach so long as the query data being sent to AS112 servers is recognised to be junk that only leaks by accident; since it's generally private network PTR query traffic the potential for exploitation by bad actors (malicious AS112 node operators) is arguably low.
> 
> However, in the case of these doh resolver domains, there is the potential for a bad actor to respond with an unauthorised list of DoH URIs and steal the resolver traffic of a large array of end-users whose local (or configured) resolvers don't implement the mechanisms described in this draft. This would be a bit like DNS changer, but without the need to infect individual end-hosts..
> 
> I think this a problem.
> 
> I think (in contrast to the thought at the microphone) if we mention blackholing at all it ought to be of the form "don't ever do this because it would be bad for the following reasons".
> 
> 
> Joe