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

[bmanning@xxxxxxxxxxxxxxxxxxxx]

placed in this context, I beleive you have described the problem space
as I (roughly) understand it.  and while you characterize this as a strictly
operational issue and therefore out of scope for DSSA, I posit that it does
or wil have a very significant impact on the perceived stability of the DNS
and should therefore find a home someplace.

/bill


On Tue, Oct 25, 2011 at 08:30:28PM +0000, James M. Galvin wrote:
> 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.)
> >>>>>
> >>>>>