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

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Dec 2010 15:39:21 -0800

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Dec 2010 02:14:25 +0000

> Date: Sun, 5 Dec 2010 15:39:21 -0800
> From: Paul Hoffman <[email-masked]>
> 
> 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.
> 

referring to two threads from 2008 where this was pretty well hashed out:

http://article.gmane.org/gmane.ietf.dnsext/11732
http://article.gmane.org/gmane.ietf.dnsext/11769

and to my comments on another (current year, 2010) thread:

http://thread.gmane.org/gmane.ietf.dnsext/17108/focus=17116

my current comments are just these four:

1. if dnssec deployment the motive, then SIG(0) as specified today will
   just work, no relaxation of any specification would be required.

2. if we're going to support the non-dnssec case, then we should do this
   in-band without a new transport, and the relaxation to TKEY mentioned
   in the above references would be the only specification needing changes,
   and that relaxation would be completely harmless to the installed base.

3. if we're going to do a new transport in spite of #1 and #2 above then
   that transport should be datagram oriented, meaning DTLS rather than HTTP.

4. if we're going to use HTTP in spite of #1, #2, and #3 above then we
   should define an XML schema for DNS transactions so that they can be
   carried by either HTTP, HTTPS, or other XML-bearing transports, and use
   a JSON style URI syntax to place this service within a web-dns server.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

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

I disagree with both of you here.

Reading through Paul's draft, it seems to be using application layer
transports which I find inappropriate for a facility that is really
tied to the transport/session boundary.

Reuse of code is good. Reuse of protocol is less so.

I took a look at the possibility of using TKEY when designing DPLS. I
don't see it as viable for the following reasons:

1) The spec is old, the key exchange proposed is obsolete. It would
need a substantial revision to be acceptable

Since most DNSSEC implementations are built on libraries that include
SSL support, it is natural to look at re-use of the TLS key exchange
rather than revise TKEY, use IPSEC or design from scratch.

2) Any spec should allow (but not require) DNS resolvers to be
operated without server side per connection state. This really calls
for a ticket based scheme and this is not currently anticipated in
TKEY/TSIG

3) If we are going to address (1) and (2), we might as well address
the main reason that DNS messages between an endpoint and resolver
would have to be pushed into TCP and that is that in DNS over UDP
there is exactly one request packet and exactly one response packet.

4) DTLS and IPSEC are really not suited to DNS. They provide far too
many features. We really need a profile and apply a part of the stack.

So the approach taken in DPLS is:

1) Re-use the existing TLS key exchange to establish a ticket that MAY
contain the connection state if required

2) Allow one request packet to be followed by multiple response
packets. This does not significantly increase server complexity as
allowing multiple request packets would and the client can cope with
multiple responses as it is only querying one resolver at a time.

We are currently looking at making the following changes

1) Use EDNS(0) for signaling the existence of the capability

2) Revise the Extended Service Discovery hooks

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Dec 2010 14:57:33 -0800

>http://article.gmane.org/gmane.ietf.dnsext/11769

There was a side-thread on root signing, a side-thread on extra random bits in the query, a side-thread on session cookies, a short useful thread on anycast resolvers, and a valid criticism of TKEY that you said "was not part of your problem statement". I think "hashed out" might be a bit of an overstatement for that thread.

>http://thread.gmane.org/gmane.ietf.dnsext/17108/focus=17116

...which is much less specific that your earlier postings.

>   a JSON style URI syntax to place this service within a web-dns server.

We probably have different threat models. Can you clarify?

- As I said in my draft, I consider bad DNS middleboxes a problem to be solved; your #1 and #2 above do not seem to consider that a problem. Is that correct?

- I consider a trivial CPU denial-of-service attack on the responder to be significant. As the TKEY RFC boldly states, "Protection against denial of service via the use of TKEY is not provided." Your #1 and #2 above do not seem to consider this a problem. Correct?

For #3, I agree from a cleanliness standpoint. I consider "easy for a DNS operator to set up" to be fairly important, and thus chose well-known toolkits. If people really don't operational ease that is important, and don't care about helping first hop resolvers that are behind bad DNS middleboxes a problem, I can se "DNS-over-DTLS" as a viable solution to that limited problem.

I have no idea what would motivate you to suggest the large extra complexity of #4. Base64-of-DNS can be carried by HTTP and HTTPS, and "XML-bearing transports" is thus not needed to solve the problems listed.

Please do say whether you agree with my assessments that you do not care about the two problems I listed in the document and above, or if you do care but think that your proposals actually deal with them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Dec 2010 19:19:27 -0500 (EST)

> I have no idea what would motivate you to suggest the large extra complexity of #4. Base64-of-DNS can be carried by HTTP and HTTPS, and "XML-bearing transports" is thus not needed to solve the prob…

It is very worrysome when people say "Oh, I know. I will just use port
80/443 and all my problems will go away". The internet is not port 80/443
and piggybacking DNS into HTTP (whether base64 or xml) is a bad design.

Avoid adding more bootstrap problems (to do DNS, I need HTTPS, for which
I need DNS).

Do not reduce the security of a crypto system to the most vulnerable
part of two cryptosystems with totally different trust models (X.509
and DNSSEC)

As for the last mile... Phones can now play HDTV. Surely they can do some
validating resolving using DHCP supplied forwarders. This should work
in most cases. Using one root key (or possibly a very few preloaded keys)

For those cases where it does not, because DNS modifications by third
parties are desired, these should be established as much as possible
through already known secure channels. This could either be the DNS
modifier service publishing a DNSSEC signed public key for query
transactions to its systems from untrusted networks - to be obtained
via generic DNSSEC protected queries, or a pre-loaded public key via
another medium (an X.509 cert?)

Putting DNS in HTTPS via stacked content encodings will just lead to
"very very deep packet inspections", and more HTTPS "friendly" man in
the middle attacks on ignoring certificate warnings to the enduser.

And if we are going to define a new method to protect queries for the
last mile (which could be across the world), we might as well add
optional encryption to it to provide privacy, and avoid another dnscurve
discussion.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Dec 2010 16:49:36 -0800

At 7:19 PM -0500 12/6/10, Paul Wouters wrote:
>80/443 and all my problems will go away".

That is true, which is why I didn't do it that way. I made sure that everything was done properly in HTTP and TLS.

> The internet is not port 80/443

If port 443 is unmolested on more transits from end hosts than any other port, and unknown ports are routinely blocked (as many of us found in hotels for the IETF in the Netherlands), then using 443 properly is possibly a better design than "use a port that is known to be blocked in many scenarios". It's a question of availability versus purity, and I chose availability; you might choose purity.

>Avoid adding more bootstrap problems (to do DNS, I need HTTPS, for which

Why do you DNS to do HTTPS if the client has the key used by the server in their trust anchor store (as I specfied in the draft)?

>part of two cryptosystems with totally different trust models (X.509

If the key of the server is known to be in the trust anchor store, where does the trust model of X.509 come into play?

>in most cases. Using one root key (or possibly a very few preloaded keys)

If all last-hop routers are on the same network as their trusted DHCP server, you are correct. That was not an assumption that I made. When I travel, I want to continue to use my home ISP's DNS service, not the crap that Starbucks hands me.

>another medium (an X.509 cert?)

I cannot parse that paragraph, and I would like to because I think we might be in agreement. Please try again.

>the middle attacks on ignoring certificate warnings to the enduser.

Quite possibly true. I expect that the wrapped-in-HTTP protocol to not be used much, but I see no reason not to offer it, given that the same server will be running it under TLS. If you don't want to serve it (and I can see reasons not to), you don't have to.

>optional encryption to it to provide privacy, and avoid another dnscurve

Right. I'm confused, then. TLS offers encryption: why are you saying we don't want it?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Dec 2010 01:32:40 +0000

there are two replies here.

> Date: Mon, 6 Dec 2010 14:57:33 -0800
> - As I said in my draft, I consider bad DNS middleboxes a problem to
> be solved; your #1 and #2 above do not seem to consider that a
> problem. Is that correct?

i'm giving you a choice. if you think dnssec will be deployed, one option.
if you think it won't be deployed, another option.  note for the gallery--
#1 (if you think dnssec is going to deployed) and #2 (if you don't) are
my proposed existing answer to the problem statement of paul hoffman's draft,
and the rest of this is just selling past the close as far as i'm concerned.

> - I consider a trivial CPU denial-of-service attack on the responder
> to be significant. As the TKEY RFC boldly states, "Protection against
> denial of service via the use of TKEY is not provided." Your #1 and #2
> above do not seem to consider this a problem. Correct?

i expect people to implement it sanely or not at all.  the fact that the
RFC does not talk about cpu-dos protection doesn't mean that trivial rate
limiting and trivial preference lists don't address the problem adequately.
as marka has said here several times, a full resolver should know who its
clients are or should know where they might be coming from.  (though opendns
and google don't have that option, most last miles are same-perimeter.)

> For #3, I agree from a cleanliness standpoint. I consider "easy for a
> DNS operator to set up" to be fairly important, and thus chose
> well-known toolkits.  If people really don't operational ease that is
> important, ...

which toolkit is required does not bear on ease of setup.  people install
from pkgsrc, sunfreeware, ports, packages, rpm's, .deb's, and etc.  the
total list or depth of dependencies are in 2010 irrelevant to operations.

> ... and don't care about helping first hop resolvers that are behind
> bad DNS middleboxes a problem, I can se "DNS-over-DTLS" as a viable
> solution to that limited problem.

people who care about bad middleboxes are already using vpn's because of
the many non-dns forms of damage they also expect.  i don't think that we
should start a war of escalation against middlebox vendors where every
protocol finds its own workarounds and every middlebox vendor breaks
whatever they still can.  this is an incredibly important philosophic
point in light of the ongoing debate about "network neutrality".

> I have no idea what would motivate you to suggest the large extra
> complexity of #4. Base64-of-DNS can be carried by HTTP and HTTPS, and
> "XML-bearing transports" is thus not needed to solve the problems
> listed.

that's what kaminsky did in his work in this area, except without base64,
since everything after the crlf-crlf that terminates the http headers can
safely be binary.  i'm suggesting that an xml schema, even if binary xml,
would also be useful in other applications.

> Please do say whether you agree with my assessments that you do not
> care about the two problems I listed in the document and above, or if
> you do care but think that your proposals actually deal with them.

i think that you should use #1 or #2 depending on whether you believe that
dnssec will be implemented.  i do not think we need any new protocol work
in this area.  our discussions of #3 or #4 are just two friends talking.

---

> Date: Mon, 6 Dec 2010 19:19:27 -0500 (EST)
> From: Paul Wouters <[email-masked]>
> 

i *would* agree except for the success of skype and bittorrent.  the market
is always attracted to stuff that just works.  after a decade we're still
trying to get ip fragmentation fixed so that edns can work, and most days
i think that's a good fight even if it takes two decades.  but it's hard
to ignore the installed base.  i *do* agree to this extent: since this
is a last mile issue where vpn's are already in common use to deal with the
extraordinary brokitude of middleboxen, we should just presume on vpn's here.

(as this is not a server-to-server proposal, the fact that vpn's don't scale
to that use case is not important to the discussion.)

> in most cases. Using one root key (or possibly a very few preloaded keys)

noting, this is my preferred model also.  we have to deploy dnssec for many
reasons.  once deployed it will have many positive impacts including making
the last mile secure, either by virtue of end-to-end validation, or by
virtue of making SIG(0) "just work", depending on how each implementor
decides the question of "heavyweight?".  let's use the architecture we've
defined for Secure DNS (dnssec, tsig, tkey, sig(0), whatever else) or let's
change it but let's not add more ad-hoc crud like "0x20" without having
explicitly decided to either implement Secure DNS or redesign Secure DNS.

> another medium (an X.509 cert?)

while i agree that a voluntary dns modifier service could do this, the model
has to accomodate the current involuntary dns modifier "services" as well.
(and it does, because a full resolver can do dnssec validation, and their
stub clients can use sig(0)... but i want to make sure this is mentioned in
the specific context of the above-quoted remarks.)

> ... if we are going to define a new method to protect queries for the

i'm hoping that the fact that last miles might be across the world won't
affect any part of the DNS design, and that the business and operational
models that seek to expand the definition of "last mile" in this way will
continue their struggle without protocol-revision support, so that we can
avoid another client-ip discussion.  but i think we're both likely to be
disappointed about what discussions we hope can be avoided.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jay Daley <[email-masked]>
Date: Tue, 7 Dec 2010 17:01:30 -0500

> 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.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Dec 2010 17:13:46 -0500

[no hat]

> 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 ar…

I note that just about every hotel I've ever been in has this problem,
so it's not like it's a total non-problem.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Dec 2010 14:17:03 -0800

> so it's not like it's a total non-problem.

Which is why you should always run an sshd on port 443 at your home institution and tunnel all traffic through it: its about the only thing that does work (reasonably) reliably through b0rken netwonks [sic].

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Dec 2010 23:03:08 +0000

> Date: Tue, 7 Dec 2010 17:13:46 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> > 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.
> 

and yet, dns isn't the only protocol that hotels mess with, and folks who
care about this mess are already using some form of vpn, so it's not like
this is a new or dns-specific problem.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Dec 2010 09:36:28 +0100

On Tue, Dec 07, 2010 at 02:17:03PM -0800,
 Nicholas Weaver <[email-masked]> wrote 
 a message of 19 lines which said:

> Which is why you should always run an sshd on port 443 at your home
> institution and tunnel all traffic through it: 

I assume that every member of this working group do something similar
(but think of Joe User, who does not have a dedicated server with a
sshd). The problem is "do we take this fact into account when writing
RFCs?" Because, then, one could say (and I suspect this is what you
meant) "the problem is solved, everything works, we don't need new
protocols".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Dec 2010 09:40:03 +0100

On Tue, Dec 07, 2010 at 11:03:08PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 19 lines which said:

> and yet, dns isn't the only protocol that hotels mess with, and
> folks who care about this mess are already using some form of vpn,
> so it's not like this is a new or dns-specific problem.

>From my experience with hotels, DNS is the most common practical
problem, among the protocols I use (SSH, HTTP and HTTPs, XMPP). If it
is solved, the need for a generic tunnel (IPsec or SSH) would
seriously diminish.

In the future, with mandatory filtering of Wikileaks, things may be
different and we will need to tunnel everything. But not yet today.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Dec 2010 09:43:44 +0100

On Mon, Dec 06, 2010 at 02:14:25AM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 48 lines which said:

> use a JSON style URI syntax to place this service within a web-dns
> server.

I know that the IETF is not to be used for personal training but,
nevertheless, I wonder what is a "JSON-style URI"... (And I have read
and - I believe - understood RFC 4627 and 3986.)
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 11:42:03 -0500

It does seem somewhat overkill to use an IPSEC VPN just to protect the
DNS when surfing the general inter-web.

I much prefer a model for road access in which I have secure DNS
resolution plus SSL tunnels for my SMTP and corporate POP/IMAP and go
direct for the rest.

Routing streaming video through a VPN located the other side of the
planet is rather a bore.

With all these proposals 'a really sophisticated user can hack
something together that is clunky but almost works' is not an argument
against doing the job right in my view.

The reason that I am working on DPLS is that Comodo already offers
curated DNS as a product and we have over a million users. While we do
provide a client, I would much prefer to allow the technology to be
built into the O/S and/or applications direct.

I have looked at DNSCurve, but I prefer Kerberos tickets to an ECC approach.

I have looked at DTLS but that tries to provide a general purpose
transport and I think the DNS does actually merit a one off package
format given the unique constraints. At the very least it would be
necessary to constrain DPLS significantly.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Dec 2010 17:05:12 +0000

> and - I believe - understood RFC 4627 and 3986.)

I guess Paul meant "RESTful".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Dec 2010 18:06:24 +0000

> Date: Wed, 8 Dec 2010 17:05:12 +0000
> From: Tony Finch <[email-masked]>
> ...

yup.  too many timezones, too few hours.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Dec 2010 10:35:21 -0800

> built into the O/S and/or applications direct.

The DPLS draft uses "curated DNS", but in a way that seems to indicate
further detail is forthcoming.  As it stands, it appears to say something that
boils down to "we select which parts of the DNS namespace are visible
to the user".  That seems to be separate problem space from securing the
hop to the DNS resolver where you are getting whatever view of the
DNS namespace you get (full, split, curated, poisoned).

If I understand your problem space right, in other words, it appears to
be a subset of the larger problem space.  I'd rather tackle the whole
space at once if it is going to be a standards-based solution.

My own take, personally, is that DTLS is actually a reasonable candidate
for this.  It has simple return routability checks that make DDoS a bit
harder, it ties pretty well into TLS models that most people understand,
and the chances are that the code will already be available to many OSes
for other reasons.  The real question for me is whether the overhead is too
painful, and I don't really have data on that.  If you do, I'd be interested
in hearing about it.

regards,

Ted Hardie

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Dec 2010 10:57:27 -0800

>painful, and I don't really have data on that.  If you do, I'd be interested

I think DNS-in-DTLS is probably fine if we don't think that the issue of firewalls that block everything other than 80 and 443 are a problem. I still consider that a problem; maybe I stay in different hotels than you do.

(Before anyone says "DNS-in-DTLS on port 443", please remember that there is zero chance of getting this on standards track, and it is important to have whatever we produce as a standard.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 15:13:20 -0500

Use SRV records for discovery and you can have as many ports as you like.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 15:21:47 -0500

No DPLS is intended to address the whole solution space. That is only
one of the use cases mentioned.

The reason I put that in there is that there are a lot of people in
this WG who have the notion that DNSSEC is going to force people to
route domains that they don't wan't to. Just like open port IPv6, it
ain't going to happen.

People have very good reason for adopting the security restrictions
they do. End-to-End DNSSEC is not a viable model for most enterprises
and it is not actually a desirable model for home use.

My problem on DTLS comes down to the fact that DNS is one UDP packet
request and response. And that starts to become very confining when
records are carrying RSA signatures.

I would like to have a mechanism that allows me to have one UDP
request packet followed by a reasonable number of responses.

Given that I would want to profile any solution anyway, and given that
packaging is not very difficult to implement, I don't see much value
to using DTLS here. While using the TLS key exchange to obtain a
ticket is very useful indeed.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Dec 2010 17:47:10 -0500 (EST)

On Wed, 8 Dec 2010, Phillip Hallam-Baker wrote:

> End-to-End DNSSEC is not a viable model for most enterprises

For argumentation against untamperable security features being
undesriable, please see RFC 1984.

Rewriting DNS packets is not a viable model for most enterprises, and
it is a continued battleground for people by many commercial entities
to grab the attention span of the home user (you might be familiar with
Verisign's attempt in the past, or perhaps with Rogers current policy).

DNSSEC is the solution in general. VPN with corporate DNS servers
is the enterprise solution (L2TP/IPSEC or IPsec/XAUTH or any of the
openvpn/sslvpn variations that can assign DNS servers)

> request packet followed by a reasonable number of responses.

Or one response with more Additional Answers in a larger UDP packet? Also,
running a local validating caching resolver greatly reduces lookups
required, especially for typical users going to the same subset of domains.

I've actually have a very good successrate using ns.xelerance.net (public
dnssec enabled resolver) with a local resolver on my laptop while travelling.

Capturing the IP stream seems to become more popular then capturing the DNS
answers.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Dec 2010 17:59:15 -0500

Speaking as chair, but without having consulted Olafur:

> Capturing the IP stream seems to become more popular then capturing the DNS

I've been working on some more comprehensive remarks about various
topics in this thread; dayjob and snowstorms keep interrupting, so my
apologies.  But the above makes me think that some serious empirical
data would be very helpful in determining whether the "interfering
middleboxes" are a real issue, and whether anything we do for the DNS
is likely to help.  The only real evidence I've seen on this to date
suggests that interfering middleboxes are in fact a problem, and one
that I think we have reason to take seriously.  But I'm open to
arguments.

A

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Dec 2010 18:03:17 -0500

> Use SRV records for discovery and you can have as many ports as you like.

<soapbox>

Yes, but SRV records also lead to multiple DNS round trips, which can lead to user unhappiness....

</soapbox>

In this particular applications that probably not an issue, but I saw a soapbox and stood on it....

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 18:01:37 -0500

There is a huge difference between having random DNS servers rewrite
DNS responses for their own commercial interests and choosing a DNS
resolver with a declared policy.

I have no intention of opening up my systems to route DNS names
controlled by Russian gangsters.

An RFC written 14 years ago by people who were rather naive as to the
real issues of Internet crime does not persuade me.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 18:22:23 -0500

That sounds like a good plan. In particular I would like some firmer
data on the following issues:

1) Size of packet allowed
     Is restriction to 500 bytes an issue?

2) Fragmentation
     Will middleboxes fragment large packets or just drop them?

3) Intermediation.
     Is interception of traffic on the DNS UDP/TCP ports an issue?

There are most definitely middleboxes that cause real issues due to
cretinous implementation. The question is how common they are.

[In the main however, my personal experience has been that the
majority are so shoddily built that they don't last very long. I have
a large box of Linksys, Netgear, Belkin etc. WiFi routers that all
stopped working reliably within about a year. So maybe there is some
hope attrition will fix some of this.]

In general though, anyone who is worried by the possibility of
interception needs to have a plan to get round carrier level DNS
redirects.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Dec 2010 19:05:35 -0500 (EST)

> that I think we have reason to take seriously.  But I'm open to

It would be ideal if we could get the RIPE Atlas probes that are deployed
to do an inventory to see about the scale of this problem.

http://atlas.ripe.net/

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Dec 2010 19:11:03 -0500 (EST)

> controlled by Russian gangsters.

Your desire for your own custom local policy is duly noted.

>>> and it is not actually a desirable model for home use.

But please stop arguing DNSSEC is not a valid local policy to choose for
others - especially speaking for "the world at large"

You can't have the cake and eat it too.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 19:12:51 -0500

I think we can fix this in the general with a meta-query, but only
after we have cleaned up Extended Service Discovery in general.

In this case, it is not relevant as the general idea is going to be
that the client establishes a long term relationship with a resolution
service that is then used exclusively until reset.

So we are talking about a couple of extra DNS round trips per O/S
reset or application install. I am not going to get at all worried by
that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 19:51:51 -0500

When you have 30 million users opted into your policy it is a bit more
than a 'local policy'.

If you stop asserting that support for local DNS policy that overrides
the default is not a valid requirement then I won't have to keep
giving use cases that prove that you are wrong.

People want an Internet that is safe. Please stop trying to impose
your personal political ideology on this technology.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Dec 2010 20:22:14 -0500

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

> reset or application install. I am not going to get at all worried by

Yes, fully agree that for this (and similar applications) the extra RTT is insignificant,  'twas more of a general statement, and I (apparently unsuccessfully) tried to mark it as such...

W

---

From: Brian Dickson <[email-masked]>
Date: Wed, 8 Dec 2010 21:47:43 -0400

Hi, Phillip,

In the interests of clarity, can I get a yea or nay, on a paraphrasing
of the policy you want to implement?

Is it the case, that you want to do all of these:
(a) have a resolver that speaks DNSSEC, to authority servers
(b) substitutes or deletes some subset according to some kind of
policy mechanism, or manual intervention
(c) serves up the results to a client base, without having to re-sign
the results?

Is this the objective you're trying to achieve?

I think that there may be ways to accomplish the above, while still
using DNSSEC, albeit in a kludgey, non-traditional way.

The important question is:
Is having clients install some trust anchor acceptable, e.g. provided
along with a stub resolver package?

Observe - DNSSEC guarantees the ability to validate results, but
doesn't necessarily guarantee receiving any results at all, since it
cannot.
Or, if two "valid" (but conflicting!) alternative results might be
received, if it gets one or the other, cannot differentiate them per
se.

By having both a "real" trust anchor (the anchor for the signed root
zone), *and* a private trust anchor which pretends to authoritatively
deny everything (root down),
you can selectively present authoritative data for "real" domains, or
"private" (fake) NXDOMAIN-everything results which are signed by the
private trust anchor.
(Think of TLD zones, containing just the apex and a single wildcard
'*' entry, signed and whose root DS entries are signed with the
private trust anchor.)

(To paraphrase the MythBusters, "I reject your reality, and substitute my own.")

It's a nasty, ugly hack, but uses DNSSEC, and thus doesn't require
non-DNSSEC extra stuff to work. It secures everything to the last
mile, too.

Would it work? (I think so.)

Is it an acceptable hack?

(That's a non-rhetorical question, BTW.)

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 21:15:42 -0500

Yes it is possible to do trust management at the endpoints.

But even in the PKIX stack that is expressly designed to support that
model and no other the complexity of doing so is kludgy beyond
comprehension. As in the US government has managed to spend heroic
quantities of cash trying to make that model work.

Writing the protocol is one thing, getting the policy data out to the
endpoints is quite another.

Now this can be made to work if enough consulting dollars are thrown
at it. Which is for some people not merely a feature, it is their
principal design objective. But it is really hard to get to work
right.

And if you don't get it right you have to get into the game of
patching code at your endpoints.

It turns into a hack even if you plan the system as a PKI from day one.

If you do not require non-repudiation then a key-centric approach such
as XKMS is better in my view.

There are a lot of devices that I would want to have hooked up to a
secure DNS that are not going to be able to process public key crypto.

The other reason to do DNSSEC processing at the resolver and rely on
those results is that the resolver is much better placed to collect
the context data that makes it possible to decide what the next step
should be.

At the moment nobody can tell me how applications should do in
response to DNSSEC authentication failures. Do they refuse to go to
the site? Do they go there anyway? At this point we do not consider
warning boxes to be acceptable, if the machine has no idea what to do
then why expect the user to have a clue?

Every time a stupid popup appears on her screen, my wife calls me on
the telephone to ask what to do. She has a degree in rocket science
from MIT plus an MIT PhD. We are not putting any more popup boxes in
the browser.

A DNSSEC aware resolver can store state and that can allow it to make
a better decision. If a DNS server is no longer correctly signed but
none of the records have changed it is probably still safe to go
there. If on the other hand the zone is not signed and everything has
changed and it is a known phishing target then it is probably safe to
conclude that there has been some form of attack.

I do not know any way that I can make the same quality of decision
based on the information that is plausibly available at the endpoint.

so an important additional objective here is

(d) works out what is the best response given the data available and
advise the client accordingly.

This is anti-virus for your DNS and that is how it is sold. Or would
be if we charged for it (the basic AV is free but there is a paid
phone support option for all your PC related problems.)

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Dec 2010 10:19:12 +0000

> service that is then used exclusively until reset.

That's not how it works. Most devices are mobile and change their connection frequently. Your resolved changes when your connection changes - you want the resolved to be close to your point of connection.

Also I like the idea of doing a SRV lookup to configure your resolver when you can't yet do DNS lookups because your resolver isn't configured.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Dec 2010 11:01:39 +0000

On Thu, 9 Dec 2010, Tony Finch wrote:
>
> That's not how it works. Most devices are mobile and change their
> connection frequently. Your resolved changes when your connection
> changes - you want the resolved to be close to your point of connection.

Sorry, "resolver" not "resolved". Damn you, autocorrect!

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 08:34:36 -0500

> That's not how it works. Most devices are mobile and change their connection frequently. Your resolved changes when your connection changes - you want the resolved to be close to your point of conn…

The server can change frequently without having to change the
resolution service.

Anycast is frequently used to allow this. We may well develop other
schemes in due course. That is why I see service discovery to be a
useful component in a general solution.

> Also I like the idea of doing a SRV lookup to configure your resolver when you can't yet do DNS lookups because your resolver isn't configured.

You can use the locally advertised DNS as bootstrap. Thats not
difficult to work out how to do. I had thought that was obvious.

Thats why I have a fingerprint mechanism for verifying the service in
the -01: To allow the bootstrap connection to be authenticated out of
band.

When it is first configured, the client pulls service from either the
local net via DHCP or via a trustworthy resolution service defined by
the manufacturer. If the device is capable of supporting the choice,
this can be left to O/S install.

An authorized administrator can override the original setting. Either
to use local DNS or to use a different resolver that is identified by
domain name.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Dec 2010 14:10:47 +0000

> The server can change frequently without having to change the

I am talking about devices that are mobile between multiple networks
managed by different providers. This is normal since one prefers not to
use 3G cellular connectivity if there's a local WiFi network one can use
instead.

> difficult to work out how to do. I had thought that was obvious.

You seem to be talking about 3rd party DNS resolvers, whereas I thought
the topic was securing the connection between the device and the local
network's resolver. The local resolver still needs to be secured in order
to bootstrap a third party resolver in the way you suggest.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 11:09:42 -0500

In my model the local resolver goes away except for possible one-time
use in configuration and/or for wifi config.

A DNS resolver is a trusted service regardless of whether DNSSEC is
deployed. The model of picking up the DNS resolver via DHCP was
adopted in the era when a major consideration on the design of a
machine was if it would fit into a freight elevator. It is bogus.

It is a model that is entirely inappropriate to modern computer use.

At one time my machine would take notice of the domain prefix
advertised in DHCP as well. I am just saying, ignore the DNS server
except to the extent that it may be necessary to do so in order allow
the DNS to be hijacked if necessary to get a connection.

If I am sitting in Panera, my machine would try to connect to my
chosen DNS resolver. If bocked it would then sense that it is on a
WiFi connection and allow limited use of HTTP/HTML to accept the
connection terms.

I would use the same DNS resolution service whether connecting over
3G, Edge, WiFi or avian carriers. I might use a different server but I
would use the same service.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Dec 2010 16:18:28 +0000

> use in configuration and/or for wifi config.

We have to be able to secure the link to the resolver without forcing
everyone to change their service model.

I don't disagree with your point that it would be better for everyone to
use a trustworthy resolver instead of whatever is provided by their
connectivity, but this is orthogonal to the low-level mechanism of
securing the data channel.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Dec 2010 14:37:05 -0500 (EST)

On Thu, 9 Dec 2010, Phillip Hallam-Baker wrote:

> A DNS resolver is a trusted service

Only if you call "forced to use our DNS" as "trusted".

It is not neccessarilly trusted if you ever move into business
environments with multiviews and want to reach a local resource.

Or if you're in the office of a large TLD operator, and they block VPN
and port 53 to everything but their local resolver

Or when the company you are in uses a fake TLD such as .internal.

The proper modern way of resolving is to use the DHCP assigned resolver as
a forwarder for a locally running validating (dnssec) caching resolver.

> would use the same service.

Again, this is your local client policy. It does not fit all.

unbound for instance, can deal with switching between dnssec and non-dnssec
aware forwarders on the fly (using unbound-remote triggers from networkmanager)
and for instance drop part of the cache when switching back to a dnssec aware
resolver.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Dec 2010 15:04:10 +0100

On Wed, Dec 08, 2010 at 07:51:51PM -0500,
 Phillip Hallam-Baker <[email-masked]> wrote 

> your personal political ideology on this technology.

I have no problem with people expressing political views. I am more
concerned when people disguise their own views under blanket
statements like "people want this or that". I suggest that, if we
express our political opinions on this list, we do it frankly and we
do not recruit "the people" when we want an argument of authority.