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

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 6 Dec 2010 14:11:33 -0600 (GMT-06:00)

Paul and all,

  Seems that your still relying on "Trusted recursive resolvers"
though.  Is that wise?

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Dec 5, 2010 5:39 PM
>To: DNSEXT Working Group <[email-masked]>
>Subject: [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.
>
>--Paul Hoffman
>
>=========================
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>	Title           : Wrapping DNS for Traffic Protection
>	Author(s)       : P. Hoffman
>	Filename        : draft-hoffman-dns-last-hop-00.txt
>	Pages           : 11
>	Date            : 2010-12-05
>
>DNS queries from one resolver to an upstream resolver are often run
>over connections with no protection of any kind.  This connection, is
>currently susceptible to both malicious and unintentional alteration
>that prevents the querying resolver from being sure that the results
>it receives are valid.  Some middleboxes can prevent a querying
>resolver that does DNSSEC validation from getting enough information
>to validate a response.  Further, a non-validating, non-iterative
>resolver querying a trusted recursive resolver is susceptible to
>active attacks in which the results are purposely altered.
>
>The protocols described in this document provide two methods to avoid
>these problems and thus make resolution significantly more secure.
>These protocols can be used between any two DNS resolvers, but they
>are particularly useful for queries from "last-hop" stub resolvers to
>trusted recursive resolvers.
>
>=========================
>_______________________________________________
>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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Dec 2010 16:47:29 -0500

I think it is a particularly bad idea to trust random DNS resolver -
whether 'secure' or not.

But in the context of a network, choosing one specific DNS resolver
service to trust makes very good sense - whether that be the Google,
DNS.com, something run in-house or whatever.

I don't particularly want providers of Internet packet transport to
know what I am doing with those packets. So I want to secure the
communication to my resolver regardless of whether I perform
end-to-end security on top.

And I certainly don't consider the fact that someone has paid for an
ICANN domain name to authorize them to advertise services to my
machines. If a DNS name is known to be malicious, I don't want my
machines to be able to see it - end of story.

So I really have no interest in performing the full DNSSEC stack
end-to-end. I do not want my clients to be balking because malicious
domains are black-holed. And in general I probably don't want to
bother about redoing the DNS security in any case. If I really care
about the security of a site, I probably want an EV cert chain.

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