Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 25 Oct 2010 12:39:15 -0500 (GMT-05:00)

Phillip and all,

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 24, 2010 5:25 PM
To: Paul Vixie
Cc: [email-masked]
Subject: Re: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)

I think that the probability of this being implemented or respected on either end is low.

Applications will set the bit without asking the user and that will give the DNS providers all the justification they need to ignore it.

I also think that the range of policy options needs to be richer than a single bit. Many people are happy to accept advertising if they are getting a real benefit in return. For example, having malware and phishing sites filtered out. The problem with ISP interception is that the end user does not get the choice.

I agree fully with these thoughts.

I think that what we need to do is to abandon the idea that applications take DNS service from the nearest DNS resolver. It is a trusted role regardless of whether DNSSEC is in use or not.

Also very much agreed here.

The only sure fire way to avoid these issues is to apply guerilla tactics. The platform needs to identify the service it is going to connect to in a way that the user can easily understand - i.e. a DNS name. So to connect through the Comodo Group Inc. curated DNS, you would type in 'comodo.com' as your DNS resolver. Or for Google it would be google.com.

There might even be different resolver policies on offer. For example there might be scada.comodo.com on offer for the most restrictive set of resolution controls and use of that service might have a subscription fee. That is not a service many people would want to subscribe to at home but might make a lot of sense for connecting critical infrastructure control systems to exactly the set of Internet resources that they need to contact and no more.

In DPLS I propose a mechanism that allows DNS resolvers to advertise a secure means of connecting via UDP. The architectural principles can be extended so that the client attempts to connect by UDP if available but will fall back to using SSL on the HTTPS port if that is blocked.

On Sun, Oct 24, 2010 at 1:49 PM, Paul Vixie <[email-masked]> wrote:

> Date: Sun, 24 Oct 2010 10:34:05 -0700
> From: Colm MacCárthaigh <[email-masked]>

>
> Sounds like an ok idea, though it's hard to see operators honouring the bit
> - but to meet your own burden of relevance; why should the DNS protocol be
> complicated with an EDNS change to facilitate the users of shared-resolvers
> when those users could simply run their own?

if it's a single bit that specifies optional behaviour that some people want,
and it's unlikely to create market pressure on people who have no need for it
on their own but who would have to implement it anyway (as i think is true of
the google proposal for adding stub IP to the recursive/authority q-tuple) and
it's not a layering change (dare i say "violation") as is definitely true of
the google stub-IP proposal, then it's effectively an FYI rather than a STD.

--
Website: http://hallambaker.com/

Regards,

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 25 Oct 2010 15:50:42 -0500 (GMT-05:00)

David and all,

-----Original Message-----
>From: David Conrad <[email-masked]>
>Sent: Oct 25, 2010 3:32 PM
>To: Paul Wouters <[email-masked]>
>Cc: "[email-masked] WG" <[email-masked]>
>Paul,
>On Oct 25, 2010, at 10:05 AM, Paul Wouters wrote:
>> unbound already supports a changing forwarder statement via unbound-control, and
>
>> even deals with the forwarder changing between DNSSEC (in)capable forwarders. And
>> it also detects stripped DNSSEC data.
>
>Wouldn't this mean the application has to know that it is behind a forwarder?  If it isn't (or it can't figure out if it is), it'll have to implement the full iterative resolver goop.  As such, I'd think the safe approach for application developers would be to link in the full iterative resolver library into the application.  
>
>Regards,
>-drc
>
>
  What you suggest may/may not be a safe approach but not very efficient.  
Surely we can do better than this.  Seems a sloppy and wasteful approach 
to me.  Seems also to me that there would be a number of new attack a 
approaches to your suggestion as well.  Just of the top of my head, my wee 
brain can conjure up some pretty simple new ones with this, your suggestion.
However they may be easily detectable and therefore soon circumventable or
made impotant and therefore not seriously considered by would be attackers.
None the less it is more important IMO that we don't ask for more trouble,
don't you think?  

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 12:21:37 -0500 (GMT-05:00)

Alex and all,

-----Original Message-----
>From: Alex Bligh <[email-masked]>
>Sent: Oct 26, 2010 1:49 AM
>To: Paul Vixie <[email-masked]>, [email-masked]
>Cc: Alex Bligh <[email-masked]>
>Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF) 
>
>
>
>--On 26 October 2010 01:59:54 +0000 Paul Vixie <[email-masked]> wrote:
>
>> am i on the wrong track according to those (three) who have +1'd this so
>> far?
>
>I am not convinced this is going to solve the problem, but I think it's
>worth our time reviewing. I will review if that is helpful.
>
>One potential problem is this: we might all want the bitfield to be
>"don't be evil", but in practice it's per the draft title "do not futz".
>I suspect some futzing may be not only non-evil but necessary (or
>lesser of two evils). I /think/ WiFi hotspots no longer futz with
>DNS to get users online (they intercept port 80), so that's not
>a problem. However, I know that in the UK (and other places) it's
>all-but-a-legal-requirement for consumer ISPs to block certain
>web content (in the UK child porn), and anyone sane does this partly
>at the DNS level. If I'm an SP I probably won't respect an "ignore
>legal requirements" bit whereas I might respect a "no advertising"
>bit; if I'm a user in $regime I may not want to set a DMNF bit
>if that actually means "be targeted by security forces". My worry is
>that the bits may end up attempting to encode policy rather than
>protocol.
>
>-- 
>Alex Bligh
>
  Great thoughts here, many I share.  Often times, perhaps too
often, policy in intemingled with protocol on more than one level,
if you catch my drift.  Blocking content at the DNS level is IMO
a good place to do it IF it is necessary.  Problem is what content
blocking IS necessary.  The IETF should not involve themselves in such
matters when considering encoding protocols.  So where possible as a
matter of policy, content blocking in some instances should be done
where possible at the App level, not at the protocol level even though
both potentials exist and one MAY have advantages over another depending
on the type of content in consideration.
Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 12:35:33 -0500 (GMT-05:00)

Phillip and all,

I fully agree.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 25, 2010 10:15 PM
To: Paul Vixie
Cc: [email-masked]
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)

I think you are creating an evil bit.

Or to be precise, a please do not be evil bit.

We have the means to allow the user to enforce their preferences in this respect, that seems a more useful approach to me.

On Mon, Oct 25, 2010 at 9:59 PM, Paul Vixie <[email-masked]> wrote:

updated informal proposal contained herein.  if you +1'd before, or -1'd, or
are still on the fence, this is worth reading and potentially commenting on.

> From: Mark Andrews <[email-masked]>
> Date: Tue, 26 Oct 2010 10:32:15 +1100

>
> > opt-in would have been the better design choice had events not
> > overtaken us.  opt-out, if it's explicit and in-band, is a carve-out.
> > those of us who know that we never want "web error redirection" should
> > be able to express this in unambiguous terms, so that ISP's and ASP's
> > who perform "web error redirection" can be held to account for their
> > conscious and deliberate choice of whether to honour our expressed
> > preferences or not.  that's what we can actually still accomplish,
> > while we wait for end-to-end DNSSEC that will drive nails into the lid
> > of the coffin containing "web error redirection" and similar practices.
>
> But we still can't be sure that they won't adapt to the presence
> of such marked queries especially if we can get buy-in from a couple
> of brower vendors along with something to help the proxies to decided
> when they should should do the same thing.

that's out of scope -- and would take more than five years to agree about.

> Why don't we do both at once?  There is a range of address modifications
> out there.  none, dns64, dns46[1], filter-aaaa, "bad" site, nxdomain.  A
> query may want some or all of these to be performed even in the presence
> of DO or CD.  Only the querier really knows what is acceptable.

> ...

> [1] Give me a IPv4 address if the site doesn't have a IPv4 address
> but has a IPv6 address.  It's the complement of dns64.

as long as it's clear that we're not changing the q-tuple between recursive
and authoritative, i'm fine with unlimited complexity in stub-to-recursive
(that is, RD=1) options.

> I can see web browers setting dns64 (vendor), bad site (user control) and
> nxdomain (user control).

so it sounds like we need a new edns option blob which is a variable length
mask (so, right now it would be one octet long), which would only be defined
for RD=1.  the first bit of the first octet would be "no web error redirect"
(NWED).  the name of the option would be "do me no favours" (DMNF).

this way we a rdns can be sure that the user has expressed no preferences if
there is no DMNF option at all, but that if the option is present, then every
bit therein is absolutely meaningful.  so, DMNF present means "user is aware
of the issues and is expressing a preference", in which case NWED=1 means the
user doesn't want web error redirection whereas NWED=0 means they do want it.
(note, we are expressing these as negatives, to ensure that rdns operators
know that the default (zero) is in favour of the potentially unwanted
practice.

there would be no ambiguity here, since someone who doesn't care at all can
just never add the DMNF option on anything, whereas someone who cares about
anything has to be explicit about every negative preference they could
potentially have.

i'm willing to write this up in this form, even given that i've missed the
-00 deadline for beijing (where i will not be present, by the way), and i'll
be happy to add any other preference bits if (1) they are only meaningful for
RD=1, (2) they do not affect the recursive-to-authoritative q-tuple at all,
(3) they can be expressed in a single binary digit ("bit"), and (4) there is
a simple unambigious one-paragraph english text that explains the meaning.

am i on the wrong track according to those (three) who have +1'd this so far?

is anyone else +1 for this approach (willing to review, etc)?

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 14:47:07 -0500 (GMT-05:00)

nick and all,

-----Original Message-----
>From: Nicholas Weaver <[email-masked]>
>Sent: Oct 26, 2010 1:11 PM
>To: namedroppers WG <[email-masked]>
>Cc: Nicholas Weaver <[email-masked]>
>Why would the misbehaving DNS authorities bother?
>
>They either have clean opt-outs (eg, Comcast's is reasonably enough and permanent: it changes the DHCP config so that in the future you get a clean resolver.  Only if you change your cable-modem does this need resetting), or DELIBERATELY unclean opt-outs (Verizon's 'change your DNS resolver settings', Bell canada's for a while was even worse: it added a cookie which simply caused the wildcard page to display a fake browser error page!)
>
>
>So in the former case, this is unnecessary, and in the latter case, why would they bother?  They've made a deliberate decision to make it hard and hostile.
>
>
>
>Additionally, the comment elsewhere that "we have a 'don't bother me': use DNSSEC and/or local resolution" is correct.  
>
>Comcast's is supposedly going away as they turn on DNSSEC (because its fundamentally incompatible in their opinion, http://www.dnssec.comcast.net/faq.htm#faq7 
>http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.1
  I was and remain more concerned about section 8.2 see:
http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.2
which suggests without defining that "the valid A record
   contained valid, lawful, non-malicious content, and there would
   otherwise appear to be no valid justification for a redirect to
   occur."  
What is 'Valid and non-malicious content' in such a 
   context?  Would some content in say the WSJ.com's web pages be 
'malicious' or perhaps playboy.com's web pages?  Some would answer yes
other would answer no, but who decides, the service provider by virtue
of their omnipitant wisdoms use of DMNF, the user or perhaps the Apps
browser/developer/provider in their own near omnipitant wisdom? My answer is
the user at the browser level where such security settings options belong.
Seems very recently though that some browser developers are also not wanting
allow for this either, see Google: 
http://www.prnewswire.com/news-releases/google-sued-for-violating-the-privacy-rights-of-millions-of-americans-105719403.html
and Firefox:
http://www.net-security.org/secworld.php?id=10042

>
>
>And I've argued repeatedly that the DNSSEC validation for "normal" records (A, AAAA, MX, etc) should be on the client as follows:
>
>IF the chain validates, accept the record from the cache.

Agreed.
>
>If, for any reason (no sig, broken sig, no root, whatever) the validation fails, do an independent fetch bypassing the recursive resolver.

Also agreed here.
>
>And this policy eliminates the problem of the lying recursive resolver, AND creates an incentive for people to deploy DNSSEC without the penalties of deploying DNSSEC incorrectly.

spot on IMO.
Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 15:04:27 -0500 (GMT-05:00)

Andreas and all,

-----Original Message-----
>From: Andreas Gustafsson <[email-masked]>
>Sent: Oct 26, 2010 2:34 PM
>To: IETF DNSEXT WG <[email-masked]>
>Paul Vixie wrote:
>> > Why doesn't that belong better in HTTP? The HTTP WG is probably better
>> > placed to define whatever a "web error" is.
>> 
>> if you get an nxdomain you won't be connecting to any web server anywhere.
>
>Maybe this can't be solved by the HTTP WG, but it could be solved by
>the web browser vendors.
>
>First of all, any improvement in "user experience" that the proponents
>of web error redirection are claiming as a justification for doing DNS
>rewriting can just as easily be implemented in the browser.  One
>difference, of course, is that any ad revenue resulting from the
>"improved experience" would then go to the browser vendor rather than
>the ISP.

  Well this would be goodness for the browser vendor/developer as you state
it.  Also though it would be an opertunity for the ISP and the browser
vendor/developer to cooperate and have cross revinue sharing agreements
so that both can benifit, or conversly if the user option is to turn
doing DNS rewriting, than neither would benifit and the user would have
the option not the browser vendor or the IxP.
>
>Second, browser vendors are in a position to defend against unwanted
>DNS rewrites, by making the browsers bypass the system resolver and
>directly query a recursive DNS server operated by the vendor or a
>third party.  If enough browsers did this, NXDOMAIN rewriting in the
>DNS would not longer be profitable.

  This would be a good outcome IMO for some users.
>
>Third, browser vendors could help raise awareness and exert pressure.
>Imagine browsers detecting rewrites and displaying alerts along these
>lines:
>
>    [Insert browser name here] has detected that your computer is
>    using a DNS server that tampers with the results of DNS lookups.
>    Most likely, this is an attempt by your Internet Service Provider
>    to replace the error message that would normally be displayed
>    when you enter an incorrect URL with a pages containing paid
>    advertisements.

  I love this alert message.  >:)
>
>    [Browser vendor] considers this practice harmful, not only because
>    it alters your web browsing experience, but also because it can
>    interfere with the operation of other Internet applications on
>    your computer and other Internet-enabled devices on your network.

  This one might be ok in some instances, not in others...
>
>    [Browser] has automatically switched to a third-party DNS service
>    operated by [company], but your other applications and devices are
>    still affected.  If your Internet Service Provider allows you to
>    opt out of DNS rewriting, we recommend that you do so.  Alternatively,
>    you can change your DNS settings to use a third-party DNS provider
>    by following the instructions at [this link].

  This alert message would be acceptable as well in some instances, but
should be set by the user, not the IxP or third party DNS provider.
>
>-- 
>Andreas Gustafsson, [email-masked]
>
Regards,
Jeffrey A. Williams