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

[Stephen Farrell <[e-mail]>]

On 26/03/2019 13:25, Joe Abley wrote:
> 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 that is likely (and I'd suspect, but don't know, that it may be)
then there's also a privacy leak - devices will make these requests
at boot time and/or application start time. That may or may not be
worse than the status-quo ante though, so is hard to evaluate. That
said, a more localised mechanism (if one exists) could be better
in both respects.

S

> 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
> 
> 
> 
> _______________________________________________ Doh mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/doh
>