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

["Mike O'Connor" <mike@xxxxxxxxxx>]

we've got a possible container in our

Vulnerabilities/Operational Issues/Infrastructure 
Vulnerabilities/Vulnerabilities of DNS Software/ topic

tentatively put it there and leave it "under discussion" for now?

mikey

On Oct 26, 2011, at 7:24 AM, Carlos M. Martinez wrote:

> I agree with Bill on this, I think it can/will have impact on the
> *perceived* stability of the DNS, and this impact should be analyzed
> somewhere.
> 
> regards
> 
> Carlos
> 
> On 10/26/11 6:55 AM, bmanning@xxxxxxxxxxxxxxxxxxxx wrote:
>> 
>> 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.)
>>>>>>>> 
>>>>>>>> 
> 
> -- 
> Carlos M. Martinez
> LACNIC I+D
> PGP KeyID 0xD51507A2
> Phone: +598-2604-2222 ext. 4419
> 
> <carlos.vcf>

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)