Subject: [Doh] on blackholing resolver-associated-doh.arpa and resolver-associated-doh.arpa

From: Joe Abley <[email-masked]>
Date: Tue, 26 Mar 2019 12:17:56 +0100

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 26 Mar 2019 14:25:55 +0100

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Mar 2019 13:34:59 +0000

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
> 
>> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/doh
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Mar 2019 16:31:30 +0100

Hi Joe,

When I sent the text (as requested), I just grabbed a copy of the text
from  RFC 8375, Section 7.  That suggests pointing to 'blackhole-1.iana.org.'
and 'blackhole-2.iana.org.'  which the AS112 project augments.  The issue
that these were built to solve, a high load of queries to .arpa for queries
leaking into the zone, seems like it might apply to this special use name.

DNAME is theoretically possible instead, but the .arpa server operators
have historically been slow to take up the idea of using DNAME (they did
not agree for .home.arpa).  I have no objection to trying again, of course,
if that is preferred.

I agree that there is a possible issue here, and I would support
documenting it.  But since the basic trust model I'd suggest for a doh
server discovered this way is equivalent to "something scrawled on the wall
of a coffee shop", I think this situation (in which they are not recognized
locally as special use names, and the particular anycast AS112 server
answering the leaked query is an attacker) is pretty much par for a pretty
rough course.

Ted

On Tue, Mar 26, 2019 at 12:18 PM Joe Abley <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 27 Mar 2019 01:05:05 +0100

> answering the leaked query is an attacker) is pretty much par for a pretty
I think it's worse than that.  What we're talking about doing is
implementing WPAD all over again.

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Mar 2019 11:29:46 +0100

Hi Ted,

On 26 Mar 2019, at 16:31, Ted Hardie <[email-masked]> wrote:

> When I sent the text (as requested), I just grabbed a copy of the text from  RFC 8375, Section 7.  That suggests pointing to 'blackhole-1.iana.org <http://blackhole-1.iana.org/>.' and 'blackhole-2.iana.org <http://blackhole-2.iana.org/>.'  which the AS112 project augments.  The issue that these were built to solve, a high load of queries to .arpa for queries leaking into the zone, seems like it might apply to this special use name.

I am familiar with the AS112 project. The crucial difference between the junk PTR queries for RFC1918 and RFC1918-like nets that are soaked up by those servers and the two ARPA domains we're talking about here are that the threat models are very different. It's a stretch to imagine that a rogue PTR response can cause anybody any harm, whereas a rogue response to these doh queries could subvert all subsequent name resolution in a way that would be difficult to detect, and there is the potential to do so on a large scale.

> DNAME is theoretically possible instead, but the .arpa server operators  have historically been slow to take up the idea of using DNAME (they did not agree for .home.arpa).  I have no objection to trying again, of course, if that is preferred.

My DNAME observation was simply to illustrate that the blackhole idea was inconsistent with the current text in the document. I'm aware of the practical problems of using DNAME in ARPA in the way that it is currently managed.

> I agree that there is a possible issue here, and I would support documenting it.  But since the basic trust model I'd suggest for a doh server discovered this way is equivalent to "something scrawled on the wall of a coffee shop", I think this situation (in which they are not recognized locally as special use names, and the particular anycast AS112 server answering the leaked query is an attacker) is pretty much par for a pretty rough course.

I think the risk is far more serious than you are implying, and to be honest I think the only useful advice here is that the mechanism should be considered harmful and must not be used.

Since the meeting this week also seemed to expose concerns about the other two mechanisms, it's seems possible that this draft has led us down a dead end.

Joe

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Mar 2019 14:21:34 +0100

Hi Joe,

Top posting, forgive me.  I recognize that this is different from junk PTR
case, but I would interested in how different you see this from the
.home.arpa case laid out in RFC 8375?  The critiques you make seem to
indicate that you would have similar issues there, but if there is a
distinction (e.g. single answers versus declared resolver), it would be
useful to draw it out.

thanks,

Ted

On Wed, Mar 27, 2019 at 11:30 AM Joe Abley <[email-masked]> wrote:

> from  RFC 8375, Section 7.  That suggests pointing to '
> blackhole-1.iana.org.' and 'blackhole-2.iana.org.'  which the AS112
> project augments.  The issue that these were built to solve, a high load of
> queries to .arpa for queries leaking into the zone, seems like it might
> apply to this special use name.
>
>
> I am familiar with the AS112 project. The crucial difference between the
> junk PTR queries for RFC1918 and RFC1918-like nets that are soaked up by
> those servers and the two ARPA domains we're talking about here are that
> the threat models are very different. It's a stretch to imagine that a
> rogue PTR response can cause anybody any harm, whereas a rogue response to
> these doh queries could subvert all subsequent name resolution in a way
> that would be difficult to detect, and there is the potential to do so on a
> large scale.
>
> My DNAME observation was simply to illustrate that the blackhole idea was
> inconsistent with the current text in the document. I'm aware of the
> practical problems of using DNAME in ARPA in the way that it is currently
> managed.
>
> I think the risk is far more serious than you are implying, and to be
> honest I think the only useful advice here is that the mechanism should be
> considered harmful and must not be used.
>
> Since the meeting this week also seemed to expose concerns about the other
> two mechanisms, it's seems possible that this draft has led us down a dead
> end.
>
>
> Joe
>