Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Antoin Verschuren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> David Conrad
> Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
> 
> As far as I can tell, Comcast's network and their recursive servers
> are not a "public resource".  As folks on Comcast's network are not
> forced to be Comcast's customer nor (as far as I know) are they
> required to use Comcast's name servers, I don't see where you, this
> working group, or the IETF has a right to determine what Comcast does.

I tend to disagree with you here.
If Comcast is selling it's service as "Internet service" the general public 
might think that that's the way it should work, and we would all suffer from 
that general public's perception. If it would break some applications, a 
general user would think that the application is broken, not "The Internet" as 
offered by Comcast. So application builders will design their products to work 
on the "broken" Comcast network, or go bankrupt.

I'm actually thinking that we are fighting this war on a wrong battleground.
Just because DNS is wrongly considered to be the easiest hammer doesn't mean it 
fits every nail.

I very much see the benefits of protecting innocent users from the bad of the 
Internet.
But if it's web pages that are the bad thing, fight that.
I'm very much in favor of writing a 
draft-arends-dns-response-modification-considered-harmful-00
I'll explain further on.

At the same time, if I had enough knowledge of http(s), I would even want to 
contribute to a draft
draft-verschuren-http(s)-intercept-and-redirect-00
Because I think that is the right battleground for this.
I don't know where such a discussion should take place though, but certainly 
not here.

So for harmful content of web pages, intercept and redirect http(s) traffic.
For unclear errors in browsers when typos are made, fix the browsers.

I'll explain where I see the conflicts.
The "Internet" has gone above a technical definition.
It's considered a brand name or at least a steady concept. (forgive my 
searching for the correct term as non-native speaker)

The same is true, or even more, for domain names.
TLD's and domain owners consider their domains as brand names, and might fight 
if somebody is affecting their autonomy.
Since the game that's being played here is not about technology but about 
dollars, image, politics and policy, consider where this fight might end.

The suggestion I'm making is not one I favor, but just as an indication of 
where the DNS redirection path might end:
If ISP's start to mess up the authoritative answers for my TLD, I might 
consider protecting my brand name with a split view on my TLD.
One view for "proper" resolvers, with real answers and NXdomains.
The other view would be for "lying" resolvers where I would enter a wildcard so 
that my "brand name" TLD would show a proper error message without adds, 
preferred search engines or harmful content instead of the one from the lying 
resolver. I would do this to protect the image of the TLD as being a "safe" TLD 
to register your name in. It would protect my TLD against redirects that are 
not considered "appropriate" for the image or local policy under my TLD.
I would make a blacklist of resolvers I know are lying, and redirect them to 
the wildcard view of the DNS infrastructure.
This might even be imposed by ignorant local governments.

This would be a war without an end, so again, I don't want to go this path.
It will be a war between the ones with power and the ones with money, and in 
the end, it does not help the "Internet" user.

So please, if harmful web content is the problem, fix that. Perhaps we need a 
screwdriver instead of a hammer.
If unclear error messages in browsers are the problem, fix that. Perhaps we 
need a saw instead of a hammer.

The dollars against politics war is one we're not going to win on instable 
technical solutions.


Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschu...@sidn.nl  xmpp:ant...@jabber.sidn.nl  
http://www.sidn.nl/
-BEGIN PGP SIGNATURE-
Version: 9.6.3 (Build 3017)

wsBVAwUBSmA6dzqHrM883AgnAQhTqggAsrRaGi/ZPuJ7ZnKUYtaKdxz7iaeyi2nU
nCT/YXI4w/OudjyRapMmTvKGgb2tmGnN1nEPUXnwraDGV628HkqU/GJG6AwTq8X+
k3S7YGC5MUjgUVG/O1fux7oSMY4YmHhMngJWpBzhsAosA1yRtAGW/9iKZTs01t1S
hYWssFkjLh+MGNn2t+FD93p8HsY4fiYcO2QZh8KZOTHPMCeezyni+ODxEMftbD+L
aQLk8Hw/xJEf3TIfR8NE1csL+jV32yWKBFAebjq3+cNtGgH7eHRHuetHjxl2L5nW
X3NK+zHswu9vvckmg5mTAoJ5u188Hgv2njS0DKFe8YdUKNK0DgNoVg==
=ib4t
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Andreas Gustafsson]

Livingood, Jason wrote:
> > TLDs, including your own zones.  This is indeed not just Site Finder
> > all over again - it's far worse, and breaks far more applications than
> > Site Finder did.
> 
> Please do send me that list of applications.  I would very much like to
> describe these use cases in the next version of the draft.

No one said anything about a list.  I'm merely making the general
point that the more zones affected, the more applications affected.
But to give one concrete example, DNS-based blacklists and whitelists
will be impacted as they rely on NXDOMAIN responses to indicate that
an address or name is not listed.
-- 
Andreas Gustafsson, g...@araneus.fi
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Jim Reid]

On 17 Jul 2009, at 10:12, Andreas Gustafsson wrote:


But to give one concrete example, DNS-based blacklists and whitelists
will be impacted as they rely on NXDOMAIN responses to indicate that
an address or name is not listed.


To give another, Internet Explorer uses NXDOMAIN responses to do a  
google search of what was in the browser bar and display the results  
of that search IIUC. This is equally as evil IMO as doing DNS  
redirection and sending the user to some ISP-supplied landing page.  
There's no need to explore this rat-hole. so please don't. The point  
here is that DNS redirection breaks the default, expected behaviour of  
a very commonly used application because the browser no longer sees  
NXDOMAIN.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Jim Reid]

On 16 Jul 2009, at 13:32, Livingood, Jason wrote:

Please do send me that list of applications.  I would very much like  
to

describe these use cases in the next version of the draft.


Yet another example. Many mail servers (including mine) reject SMTP  
connections from hosts that don't have reverse DNS. That's usually a  
strong indicator of a likely spam source. If some DNS redirector  
changes those NXDOMAIN/NOHOST responses to something else, those mail  
servers will accept inbound mail from places they wanted to reject.


Many anonymous FTP servers behave(d)this way too, at least in the pre- 
web era. IIRC, some of the most useful/popular FTP servers did this to  
encourage people to fix their reverse DNS setup.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Eric Brunner-Williams]

Antoin Verschuren wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  

-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
David Conrad
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00

As far as I can tell, Comcast's network and their recursive servers
are not a "public resource".  As folks on Comcast's network are not
forced to be Comcast's customer nor (as far as I know) are they
required to use Comcast's name servers, I don't see where you, this
working group, or the IETF has a right to determine what Comcast does.



I tend to disagree with you here.
  


I would be happy with some statement that the use of unique identifiers 
created by the IANA function, and delegated to parties which in turn 
delegate these assets to network operators, in particular AS numbers and 
address space, have some policy restrictions. I don't know what they 
are, but if operator X doesn't use directly, or consume transit that 
does use those assets (back to the pre-CIX world), then the conduct of 
operator X is not inherently subject to the union of policies of 
upstream providers, and ultimately, the policy associated with the IANA 
function. Note, I'm not asserting the existence of a policy exercised 
presently by the IANA function, only the possibility. In my fantasy life 
I'd like to see BCP38 mandatory, and the BGP trusted-chain-of-delegation 
rooted.


We have rfc1918 for "private" spaces. I wouldn't first appeal to the 
"general public perception" argument, though Antoin does point out in 
the same para (below) that the issue may not be "are operator X's 
facilities a public resource", but the market power of operator X to 
restrict third parties from offering services to operator X's 
subscribers. Note, "market power" is a local matter, applicable to the 
operator used as an example.

If Comcast is selling it's service as "Internet service" the general public might think that that's 
the way it should work, and we would all suffer from that general public's perception. If it would break some 
applications, a general user would think that the application is broken, not "The Internet" as 
offered by Comcast. So application builders will design their products to work on the "broken" 
Comcast network, or go bankrupt.

I'm actually thinking that we are fighting this war on a wrong battleground.
Just because DNS is wrongly considered to be the easiest hammer doesn't mean it 
fits every nail.

I very much see the benefits of protecting innocent users from the bad of the 
Internet.
But if it's web pages that are the bad thing, fight that.
I'm very much in favor of writing a 
draft-arends-dns-response-modification-considered-harmful-00

I'll explain further on.

At the same time, if I had enough knowledge of http(s), I would even want to 
contribute to a draft
draft-verschuren-http(s)-intercept-and-redirect-00
Because I think that is the right battleground for this.
I don't know where such a discussion should take place though, but certainly 
not here.

So for harmful content of web pages, intercept and redirect http(s) traffic.
For unclear errors in browsers when typos are made, fix the browsers.

I'll explain where I see the conflicts.
The "Internet" has gone above a technical definition.
It's considered a brand name or at least a steady concept. (forgive my 
searching for the correct term as non-native speaker)

The same is true, or even more, for domain names.
TLD's and domain owners consider their domains as brand names, and might fight 
if somebody is affecting their autonomy.
Since the game that's being played here is not about technology but about 
dollars, image, politics and policy, consider where this fight might end.

The suggestion I'm making is not one I favor, but just as an indication of 
where the DNS redirection path might end:
If ISP's start to mess up the authoritative answers for my TLD, I might 
consider protecting my brand name with a split view on my TLD.
One view for "proper" resolvers, with real answers and NXdomains.
The other view would be for "lying" resolvers where I would enter a wildcard so that my "brand 
name" TLD would show a proper error message without adds, preferred search engines or harmful content instead of 
the one from the lying resolver. I would do this to protect the image of the TLD as being a "safe" TLD to 
register your name in. It would protect my TLD against redirects that are not considered "appropriate" for 
the image or local policy under my TLD.
I would make a blacklist of resolvers I know are lying, and redirect them to 
the wildcard view of the DNS infrastructure.
This might even be imposed by ignorant local governments.
  


This idea has been discussed by others in the context of TLDs with 
"local scope", the largest examples of these are as you mention, 
associated with national governments which may impose, for local policy 
reasons, two or more "views" on a name space.



This would be a 

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Paul Hoffman]

At 9:15 AM +0200 7/16/09, Stephane Bortzmeyer wrote:
>On Mon, Jul 13, 2009 at 01:59:46PM +0200,
> Roy Arends  wrote
> a message of 33 lines which said:
>
>> SSAC's Report on DNS Response Modification
>> http://www.icann.org/en/committees/security/sac032.pdf
>
>Indeed. Good document. There is no need to discuss about
>draft-livingood-dns-lie, all the issues raised here in this WG were
>already in the SSAC document one year ago.
>
>I regret one thing with SSAC 032: they mix wildcards in the zone and
>lying resolvers. True, they have similarities but also differences
>(for instance, wildcards in a zone follow the DNS protocol, and
>therefore are compatible with DNSSEC) and I'm a bit tired of Slashdot
>discussions starting with "Comcast == Sitefinder".

I noticed this as well. Can someone from SSAC discuss here why that is the 
case? It is fairly relevant to this thread, given that a few people have wanted 
to see SAC032 discussed in the draft, but it doesn't seem relevant because of 
the difference.

--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Paul Hoffman]

At 8:16 AM -0400 7/16/09, Livingood, Jason wrote:
> > I'll speak for my parents here: a DNS resolver that reduces the chance that 
> > they'll get a drive-by malware
>> infection is something they would happily use. Having said that, a DNS 
>> resolver that gives them a page of
>> search results instead of the browser's error page when they mistype a URL 
>> is something the *do not* want
>> because it increases their confusion.
>
>IMHO malicious bots are an extremely concerning problem, and the problem of 
>bot infections is much more widespread than many people realize.  I'm in the 
>early stages of contributing to a bot-related draft at 
>http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00
> in case anyone is interested in providing private feedback (haven't really 
>found a WG appropriate for the work).

I hope that redirection is not an indicator that the -01 draft will continue to 
talk about the two scenarios as if they are somewhat equivalent.

At 4:14 PM + 7/16/09, Suzanne Woolf wrote:
>I hope redirect-01 is more strictly descriptive and can drop defensive
>terms for DNS redirect, like "enhancement" of the "user experience",
>since it's by no means agreed that crippling DNSSEC (for example)
>enhances the value of the Internet for anyone.

+1. You can talk about why you are doing what you are doing without making it 
seem that the positive values are going to be be worth the negative 
side-effects.


--Paul Hoffman, Director
--VPN Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[John Schnizlein]

Along with these good suggestions, the next draft should include a  
brief description of why the desired behavior (as seen by the user) is  
better performed through DNS tricks than through HTTP tricks.


John

On 2009Jul17, at 12:04 PM, Paul Hoffman wrote:


At 8:16 AM -0400 7/16/09, Livingood, Jason wrote:
I'll speak for my parents here: a DNS resolver that reduces the  
chance that they'll get a drive-by malware
infection is something they would happily use. Having said that, a  
DNS resolver that gives them a page of
search results instead of the browser's error page when they  
mistype a URL is something the *do not* want

because it increases their confusion.


IMHO malicious bots are an extremely concerning problem, and the  
problem of bot infections is much more widespread than many people  
realize.  I'm in the early stages of contributing to a bot-related  
draft at http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00  
in case anyone is interested in providing private feedback (haven't  
really found a WG appropriate for the work).


I hope that redirection is not an indicator that the -01 draft will  
continue to talk about the two scenarios as if they are somewhat  
equivalent.


At 4:14 PM + 7/16/09, Suzanne Woolf wrote:
I hope redirect-01 is more strictly descriptive and can drop  
defensive

terms for DNS redirect, like "enhancement" of the "user experience",
since it's by no means agreed that crippling DNSSEC (for example)
enhances the value of the Internet for anyone.


+1. You can talk about why you are doing what you are doing without  
making it seem that the positive values are going to be be worth the  
negative side-effects.


--Paul Hoffman, Director
--VPN Consortium


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Dave CROCKER]

Jason, et al,

This note suggests changes in both style and detail in
draft-livingood-dns-redirect-00.  All of the points made here have been made or
suggested by others in this thread; my intent is to underscore and elaborate on
those points, rather than to challenge development and publication of the draft.
 I’ve seen enough postings to convince me that there actual is existing practice
with significant deployment. The goal of the draft is to document that behavior.
 Debating whether the mechanism is ever reasonable or appropriate to deploy –
and what alternatives might be more reasonable and appropriate might be
productive, but not as part of the current exercise.  The current exercise is
one of technical specification.

Given the coincidental timing, however, it’s worth citing a paper being
presented at the CEAS conference today:

   Anti-Phishing Landing Page: Turning a 404 into a
   Teachable Moment for End Users

   


A few specific points:

As with others, I think the draft needs to remove its promotional, persuasive or
legalistic vocabulary.  It’s a technical document, attempting to specify
existing practice. So it should focus on technical details and operational
trade-offs, without trying to sell the reader or protect against lawsuits.  When
the document recommends a particular choice, it should simply use RFC 2119
vocabulary.  To the extent that there are tradeoffs, simply state what they are
and which one(s) the document prefers (and possibly in what context.)  That is,
what technical or operational characteristics provide the basis for a particular
recommendation?

The long thread of discussion on the dnsop list has cited a  number of
alternative mechanisms for accomplishing the same, or similar, goals as the one
described in the draft.  To properly establish the context for use of this
particular mechanism, the draft should diligently include all of these in its
discussion of background, choices and tradeoffs.  Not to debate the
alternatives, and not to provide an extensive tutorial, but to explain the
pragmatic reasons that the mechanism being specified is (regularly?) chosen in
preference to those alternatives.

The thread discussion has also produced references to a small, but very
interesting, set of RFCs. These documents provide a rich background of relevant
material; so the draft should carefully include each of these citations and
discuss them in terms of the draft.  Besides being basic due diligence, such a
discussion might mitigate some people’s concerns about the mechanism specified
in the draft.

The draft’s discussion about the presence of DNSSec contains a nice case
analysis of various configurations and scenarios, explaining how the mechanism
works within each scenario.  However it is easy to miss a key fact that the
draft should provide in a simple, summary statement:  When DNSSec validation is
performed by the user’s resolver, this mechanism will fail. While the user will
be denied access to the potentially problematic address, they will not not land
at the alternative address.  That is, this mechanism has long-term viability
only when a user’s resolver does not implement DNSSec and, instead, relies on
their operational infrastructure to validate DNS data.

The draft specifies a mechanism that appears to work properly only for a single
application service, namely the Web. Yet it characterizes all other services as
exceptions.  Instead, the draft should cast the mechanism as intended only for a
single application and should provide substantive discussion about either how
other services will continue to operate or why disrupting them is acceptable.
This discussion is really the basis for understanding when the mechanism can be
practical to deploy and when it cannot.


A deeper issue:

The draft demonstrates some confusion about the architectural role of the
service it is specifyhing.  Various postings on the mailing list discussion have
offered a variety of alternative labels to refer to the mechanism; this serves
to highlight the potential for misunderstanding what the specified service
really is and when it is really reasonable to use.  This could be caused by a
pervasive confusion about the model for DNS service that this draft is 
affecting.

A cliché in the technical community is that the only lesson of the Internet is
scaling.  While scaling to the level of a global Internet does teach quite a
lot, its lesson does not seem to be as challenging as that of mediation.
Networking is about mediated exchange.  At every level, and for nearly all
services, mediation mechanisms come into play: Between two principals, there are
typically agents in the path, providing assistance. Some assistance is simply
routing and forwarding.  Other assistance plays with the payload.  Assistance
can be supplied by an agent of one of the principals – that is, at one end of
the path –  or by an independent operator along the path.  These are impo