Subject: Re: [dnsext] New proposal for securing the last hop (and other hops)

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 7 Dec 2010 16:10:26 -0600 (GMT-06:00)

Jay and all,

-----Original Message-----
>From: Jay Daley <[email-masked]>
>Sent: Dec 7, 2010 4:01 PM
>To: DNSEXT Working Group <[email-masked]>
>Subject: Re: [dnsext] New proposal for securing the last hop (and other hops)
>
>> Greetings again. One of the items on the new WG charter is "Mechanisms that complement, or are alternatives to, TSIG and SIG(0)", and many people have decried the lack of protection for the "last hop" (stub resolver to its recursive resolver upstream) as a deterrent for real DNSSEC deployment. There are a bunch of (sometimes-conflicting) requirements for protecting such queries and responses.
>> 
>> To that end, I have created a new draft, shown below. The protocols described can be used by any two DNS resolvers, but they are probably most useful in the last hop. Instead of developing new protocols, I used existing protocols (HTTP and TLS) for which there are plenty of toolkits.
>> 
>> Comments are appreciated.
>
>I do not agree that the basic problem statement requires a new protocol to address it.
>
>Quoting selectively from the draft, the first element of the problem is:
>
>>    DNS intermediaries have been found to cause a number of tenacious and
>>    difficult-to-solve problems.
>
>Implementers only mess with DNS because it is so easy and because it has been undetectable until now.  I would suggest that making messing with DNS detectable is going to eliminate this malpractice unless it is entirely deliberate (e.g. a corporate network)
>
>But I see you've thought about that in the second element:
>
>>    Spoofing does not affect DNS
>>    responses that are protected by DNSSEC that are sent to resolvers
>>    that validate; note, however, that non-validating resolvers,
>>    particularly non-validating stub resolvers, are quite common.
>
>
>The only problem there is that DNSSEC is not yet implemented ubiquitously, and to expect anything else to have happened when the root was only signed in July and only a few TLDs/registrars offer full DNSSEC support, is unrealistic.  This second element will solve itself over time.
>
>That leaves the only the narrowest use cases of users who are behind a middlebox that is deliberately messing with DNS as part of some corporate policy and we want to design a protocol that gets around this and that cannot be trivially blocked.

  I cound not agree more here!
>
>Jay
>
>-- 
>Jay Daley
>Chief Executive
>.nz Registry Services (New Zealand Domain Name Registry Limited)
>desk: +64 4 931 6977
>mobile: +64 21 678840
>
>_______________________________________________
>dnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsext

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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext