Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Aug 2017 17:33:32 GMT

> From: Paul Vixie <[email-masked]>
 
> some time before bad people get around to using dnssec to bypass rpz,
> the spec will have to evolve to allow new signalling ("i want to hear
> both the truth and the lie, and please sign the lie with our shared key
> so i'll know it's from you"). 

I disagree.  The last year has shown there there is limited appetite
in the IETF for RPZ work

A second issue concerns the use and purpose of the DNS.  No applications
that are not DNS debugging or forensic tools want both DNS truth and
lies.  All ordinary applications want an IP address and sometimes
application protocol data such as in SRV, MX, TLSA, and TXT.  They
don't want and generally can't deal with multiple answers, as demonstrated
by the very few applications that look past the first IP address from
gethostbyname() (or modern replacements) even when the first IP address
fails.  Except for debugging or forensic tools, the application code
itself should not and even if the IETF says it should, will not care
about more than the first usable DNS result.

Users of applications might want either truth or RPZ lies, but not both
except for debugging and forensics.  Those user preferences can vary
depending on the application.  A user of ssh might want the truth,
because ssh has its own authentication system that is more secure than
DNSSEC.  The same user might choose RPZ filtering for smtp and http.
To facilitate such user choices, it would be good if applications could
tell stubs to use an alternate /etc/resolv.conf.

On the other hand, there is already signaling that provides both DNS
truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
implements kludge "signaling" to get the DNS truth, while straight
`dig` gets the possible lie.  (Note that a single system can host both
honest and RPZ resolvers.  BIND with views can distiguish requests for
truth from requests for lies with TSIG keys and answer appropriately.
You can include TSIG keys in dig commands.)

That kludge, dual-dig "signalling" would work with future RPZ installations
with real "give me both" signaling, old RPZ installations, and covert
DNS liars.  Even if a future version of RPZ has real "give me both"
signaling, you will always need and will reach first for dual digs.

The SOA added by RPZ to the additional section is perfectly sufficient
to signal the honest presence of an RPZ lie.

Vernon Schryver    [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 13:13:21 -0700

Vernon Schryver wrote:
>> From: Paul Vixie<[email-masked]>
>

i think we have to keep trying until and unless the co-chair say to stop.

> application protocol data such as in SRV, MX, TLSA, and TXT.  ...

well, yes, but a directive in /etc/resolv.conf saying what lies to 
trust, or whether to trust all of them, or whether to trust none of 
them, would be a way for a system operator or owner to set response 
policy for all applications. the resolver is a dns-aware application.

> depending on the application.

if an application wants a different kind of lies than is the default in 
/etc/resolv.conf, it will need API hooks to say so. i predict that the 
getdnsapi team would offer such hooks if there were an underlying 
protocol with knobs like that. obviously "dig" will always just print 
both the truth and the lies, and let /dev/stdout sort out the meaning.

> `dig` gets the possible lie.

alas, this is unreliable. i've been hooked up to networks with policy at 
the IP layer causing 8.8.8.8 requests to be rerouted to a local DNS 
server with advertising (NXDOMAIN substitution) support. considering 
that google's original motive for creating the 8.8.8.8 service in the 
first place was that various rDNS services were giving locally-faked 
responses to "www.google.com/A", i think this shows the slipperiness of 
the slope, in neon glowing detail.

> to signal the honest presence of an RPZ lie.

well, yes. but it may be the law of the land in some countries that 
citizens accept DNS lies, whereas foreign visitors can accept DNS truth. 
so i'd like the protocol to carry both (lies and truth), with 
policy-level digital signatures on the lies, to be sure they are coming 
from the place we're expecting our lies to come from.

-- 
P Vixie

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Aug 2017 22:50:59 GMT

> policy for all applications.

> /etc/resolv.conf, it will need API hooks to say so.

That's what I meant.
It could be done today with small, upward compatible changes to
libresolv to allow the application to specify resolver IP addresses,
port numbers, and TSIG keys.  (and equivalently in Windows)

(Note that TSIG keys in resolv.conf would help provide a trustworthy
path to your trusted resolver for reasons unrelated to RPZ.)
(well, getting libresolv to sign and check TSIG might not be that small.)

> alas, this is unreliable. 

A network that routes requests to 8.8.8.8 to inject DNS lies will also
arrange to ignore or pervert any DNS-in-band tell-the-truth signaling.
Without access to a trustworthy resolver, tell-the-truth signaling is
useless because you can't trust it.

If you have a trustworthy path to a trustworthy verifying resolver,
then by definition you trust that resolver to do the things you
want with RPZ and everything else, and so none of your applications
need both answers.
With a trustworthy resolver, you don't need in-band trugh signaling
except for debugging, and all of the many people who have debugged RPZ
installations have not needed more than log files and `dig` to different
resolvers and resolver views so far.

> from the place we're expecting our lies to come from.

No jurisdiction will allow foreign visitors to bypass local filters
forever, because foreign visitors blab both the banned data and the
banned tools.  We've a very long history of this in print media.  Recall
that the Iron Curtain borders took an extremely dim view of smuggling
subversive literature.  And didn't Tailand recently sanction some
foreigners for lese magesty in forgien on-line media?  Isn't there
talk about China blocking all tunnels including those of foreigners?

Even with the acquiescence of regimes, there are insurmountable practical
technical and non-technical issues in providing both RPZ filtered and
raw DNS answers, configuring applications, and ensuring that citizens
don't get foreign, uncensored versions of applications.  It's one thing
for a regime to allow foreigners to use foreign services (which I claim
never lasts), and quite another thing for in-country operators to
expect government censors to understand and believe that citizens can't
use the truthful results in DNS responses.  If you were a DNS operator
in China, would you ever allow your resolver to give truthful answers
about some domains in any form or in response to any signaling?--of course
not!

We're seeing something like this happen with the European demands that
the "rights to be forgotten" apply accross borders.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Aug 2017 16:50:31 -0700

> useless because you can't trust it.

i would like to be able to know that i can't trust it, rather than 
merely assuming that i can't trust it, as happens today. if neither the 
truth nor the lie is signed, i can make a red light blink, or even go 
offline, refusing the local edition of the social compact ("if you want 
to use the internet you have to accept dns answers w/o provenance.")

> banned tools.

as a frequent visitor to china, my verizon wireless roaming service is 
tunnelled back to the USA. i can read facebook, search google, and so 
on. verizon isn't a pirate -- they have a license to operate in china 
and they honor the terms of that license. but they don't sell this 
service inside china.

i expect more, not less, arrangements of this kind going forward, now 
that other nation-states are making decisions about internet content 
filtering for their citizens. note that i blogged on this specific 
point, and mentioned rpz, recently:

http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/

> ... Isn't there

not that i've heard. china has a delicate balancing act, and they do not 
seem to want to completely discourage tourism, even if that means there 
are leaks in the great firewall as a result. on wifi or wired, they 
don't know who isn't a citizen. on LTE or GSM, they do. but the tunnel i 
use is slow, and expensive for both verizon and i. i'd like to offer 
china the opportunity to carry both dns truth and dns lies, in the same 
packet, with one of them a little harder to get at using older software, 
and with newer software having a switch, "do you trust policy having 
this key?" i expect that for android and iOS devices sold in china, this 
switch would be hardwired "on".

this reflects my broader belief that neither the open source community, 
or the internet technology community, will ever be taken seriously by 
the chinese gov't if we tell them how they should run their country's 
internet or its connections to the rest of the world. if they want to be 
able to express policy data more reliably using DNS than will be 
possible in a ubiquitous-DNSSEC scenario, then we ought to provide that, 
and encourage engineers from within china to help define, model, test, 
develop, and deploy it. this would ease the complexity burden for 
companies selling internet devices and services inside china. it will 
not make anybody in the world less autonomous than they already aren't.

> about some domains in any form or in response to any signaling?--of course

as a provider i would, whether in china or elsewhere, follow the law.

-- 
P Vixie