Re: [dssa] a thread for Dakar-meeting feedback

["James M. Galvin" <jgalvin@xxxxxxxxxxxx>]

So let me take a step back here and approach this differently.

It is true that DNSSEC provides a detection mechanism against modified  
DNS responses at the point where validation is done.  It is also true  
that domain name reputation systems (of which RPZ is a mechanism to  
support them) are a DNS filtering mechanism.
Ideally the use of these two technologies is a user choice and thus a  
user expects the various notices or failure modes that may result from  
this usage.  However, many configurations are possible, including a  
service provider that imposes the use of one or more of these  
technologies on a user.
When a service provider imposes the use of an RPZ on a user, and the  
user has DNSSEC validation enabled in their local environment, the  
user will be able to detect the use of the RPZ.  However, it may not  
be possible for the user to "route" around the use of the RPZ and thus  
the user may not be able to restore their DNS usage to 100%.
This is an operational issue.  This is an issue associated with the  
use of the DNS.
We have already confirmed that when someone uses the DNS in a way that  
at least some would regard as sub-optimal if not inappropriate, that  
issues of this type are out of scope for this group.  In this scenario  
the DNS is functioning as configured.  It may not be a desirable  
configuration but that is not within scope for our working group.
I am very keen to hear from others besides myself and Bill.  Do others  
think this topic is within scope for this working group or not?
Jim





On Oct 25, 2011, at 8:19 AM, bmanning@xxxxxxxxxxxxxxxxxxxx wrote:

> local to whom?  it si rare that one finds the simple "stub-imr-auth"  
> DNS path
> in the Internet of today...  its usually (esp the coffeeshop  
> example) more like
> "stub-local cache-captive portal-forwarder-imr-auth"   and at each  
> one of those
> "hops" has the ability to inject local policy.
>
> it is somethign that needs to be addressed, if not in dssa or ssac,  
> then another
> venue.
>
> SAC050 is nice but appears to lack teeth in the face of vendors (at  
> least one)
> embedding DNS blocking technology in their product and predicting  
> ubiquitous
> deployment of same.
>
> From Pauls presentation: slide#26
>
> DNS firewalling will become ubiquitous in the same way that antispam  
> technologies did.
> DNS RPZ will create a global market of DNS firewall policy producers  
> and subscribers.
> DNS RPZ will be implemented by all DNS vendors, not just by ISC in  
> BIND (as today).
> ----
>
> as usual, YMMV, but it would not be reasonable to claim this is a  
> non-issue.
> /bill
>
>
> On Mon, Oct 24, 2011 at 06:31:06PM +0000, James M. Galvin wrote:
> > But none of this changes what I said.  It's a local operational issue
> > and not something we need to address.
> >
> > Jim
> >
> >
> >
> >
> >
> > On Oct 24, 2011, at 4:56 PM, bmanning@xxxxxxxxxxxxxxxxxxxx wrote:
> >
> > > this is the location:
> > >
> > > http://www.gcsec.org/event/dns-easy-2011-workshop/keynote-talks
> > > slides 24,25,26...
> > >
> > > the "recovery" is to use another nameserver or use a non-obstructed
> > > path.
> > > secltion of an alternate path may not be possible (the use of DNS
> > > over HTTP is not yet
> > > an IETF WG aactivity) and few people outside the odd sysadmin/dns
> > > geek can select a new
> > > nameserver.
> > >
> > > RPZ is codified mitm attacks.
> > >
> > > Pauls public statemetns don't sound like rumor - sounds like an ISC
> > > stated business model.
> > >
> > >
> > > /bill
> > >
> > > On Mon, Oct 24, 2011 at 03:58:51PM +0000, James M. Galvin wrote:
> > > > Reputation systems and DNSSEC co-exist just fine.  I take issue  
> > > > with
> > > > Paul's position as explained by Bill.
> > > >
> > > > As I understand it, the issue is that DNSSEC will detect that
> > > > somebody
> > > > is mucking with your DNS responses but the user may not know why
> > > > (perhaps it's intended because of the service they're using, i.e.,
> > > > the
> > > > ISP is filtering for you because they know what's best for you).
> > > > Worse, the user may not be able to "get around" the resolver that  
> > > > is
> > > > inappropriately (or unexpectedly) mucking with DNS responses.
> > > >
> > > > The overstated strong statement is that there is no recovery and
> > > > therefore they do not co-exist.
> > > >
> > > > That's the best that Bill could explain to me.  So, unless I'm
> > > > missing
> > > > something, there's no story here.  DNSSEC is doing its job by  
> > > > letting
> > > > you know you have a problem.  The fact that you may be subjected  
> > > > to a
> > > > reputation system unexpectedly is, well, a local problem.
> > > >
> > > > We should not perpetuate this rumor without additional facts.
> > > >
> > > > Jim
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Oct 24, 2011, at 3:20 PM, Mike O'Connor wrote:
> > > >
> > > > > hi all,
> > > > >
> > > > > here's a little thread where you can all post comments/feedback  
> > > > > you
> > > > > receive during the course of the Dakar meeting.  i'll start it by
> > > > > passing along a couple of notes i took during the DSSA-update
> > > > > session at the GNSO yesterday.
> > > > >
> > > > > Jeff Neuman (NeuStar, Registries, Vice-Chair of the GNSO Council)
> > > > > commented on our scope -- expressing concern that our scope is
> > > > > perhaps too narrow and may be misperceived by people outside the
> > > > > process as too focused on the root and TLD levels of the DNS.  he
> > > > > made the point that "DNS" means a much broader thing to many and
> > > > > they may be disappointed when they see our scope statement.  he
> > > > > encouraged us to, at a minimum, make our scope statement really
> > > > > clear in our final report
> > > > >
> > > > > Bill Manning and James Galvin had a conversation about the mutual
> > > > > compatibility of  DNSSEC and DNS RPZ (here's a Paul Vixie blog  
> > > > > post
> > > > > about RPZ - https://www.isc.org/community/blog/201007/taking-back-dns-0)
> > > > > .  Bill started with a comment that the two may be an either/or
> > > > > choice, that they may not be compatible with each other.  James
> > > > > questioned that.  Bill responded with reference to a very recent
> > > > > interaction with Paul V. in which Paul said he didn't know how to
> > > > > make the two approaches coexist.
> > > > >
> > > > > any other comments/ideas/feedback that people are hearing?  are  
> > > > > you
> > > > > finding copies of our "one pager" helpful?
> > > > >
> > > > > mikey
> > > > >
> > > > >
> > > > > - - - - - - - - -
> > > > > phone   651-647-6109
> > > > > fax             866-280-2356
> > > > > web     http://www.haven2.com
> > > > > handle  OConnorStP (ID for public places like Twitter, Facebook,
> > > > > Google, etc.)