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

["Carlos M. Martinez" <carlos@xxxxxxxxxx>]

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

begin:vcard
fn:Carlos  Martinez Cagnazzo
n:Martinez Cagnazzo;Carlos 
email;internet:carlos@xxxxxxxxxx
tel;work:+598-2604-2222
tel;cell:+598-9-9245009
x-mozilla-html:FALSE
version:2.1
end:vcard