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

[Ted Hardie <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Ted,
>
> On 26 Mar 2019, at 16:31, Ted Hardie <[e-mail]> 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.' 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.
>
> 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
>