Subject: Re: RFC proposal on DNS spoofing prevention

From: Florian Weimer <[email-masked]>
Date: Mon, 08 Jan 2007 22:29:54 +0100

I'm not sure if I've already mentioned this, but I think it's a good
idea if the document clarifies 1123 as well, and encourages name
server operators to provide TCP service (so that TCP can be used as a
fallback to avoid spoofed responses, at least in some cases).

And the document as-is doesn't say much about stub resolvers.  Is this
a problem?  (Typical implementations do not compare source addresses,
for instance, nor do they use random source ports, at least on typical
operating systems.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Jan 2007 10:48:42 +1100

> for instance, nor do they use random source ports, at least on typical

	Typical stub resolvers use whatever etherial port the OS
	gives them.  In a good OS this will be random.

	libresolv/libbind also checks the source address and port
	of the response.

	A stub resolver is also in a good position to use TSIG /
	SIG(0) to establish a cryptographically secure channel to
	the reversive server.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Jan 2007 09:52:17 +0900

bert hubert;

In your draft, it is written that:

    Third party: any host other than the resolver or the intended
    recipient of a question. The third party may have access to a
    random authoritative nameserver, but has no access to packets
    transmitted by the Resolver.

However, I think it should also be assumed that the third party has
no access to packets of authentic answers to the Resolver.

That is, if the third party can read and block the answer packets
and inject a forged answer, there is no security, of course.

I also think birthday attacks should be prevented by using the same
ID and the same source port for all the outstanding queries with the
same question to the same destination.

To avoid outstanding queries, it is too painful to wait very long
time when a query or an answer is lost.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Jan 2007 01:10:58 +0000

> same question to the same destination.

this is a fine idea and a wonderful improvement on djb's "16 upstream ports"
idea.  i'll give it a try and i'll let you know how it works.  note that in
the djb design, one would have to hash <qname,qtype,servaddr> into a 20-bit
value of which 16 bits was a query id and 4 bits selected an upstream socket.

> time when a query or an answer is lost.

and yet, it's useful to retry, and damaging to retry too soon.  therefore one
ought to wait a short total time before presuming SERVFAIL, but try more than
once within that time period.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Jan 2007 11:15:03 +0900

Paul;

> value of which 16 bits was a query id and 4 bits selected an upstream socket.

If "hash <qname,qtype,servaddr>" is already used without additional
hash with, say, timestamps, "using the same ID and the same source
port for all the outstanding queries with the same question to the
same destination" is already done. However, such hash can be computed
by all the attackers that some (pseudo) random value (e.g. microsecond
granularity timestamp of original query) should be used with hash.

In addiotion, as ID is not very long, using multiple ports still
useful to improve security, though to smaller extent.

						Masataka Ohta

---

From: bert hubert <[email-masked]>
Date: Tue, 9 Jan 2007 22:53:10 +0100

> no access to packets of authentic answers to the Resolver.

Indeed, we'll update the draft to state so. It will be posted again
tomorrow, with a bug tracker, wiki and changelog, so it should be easy to
keep track of. This was pioneered by the NSEC3 draft btw, it appears to
work.

> same question to the same destination.

Indeed, we should improve the wording of the draft that the same question
should not be in flight *with differing* source port/id's, which gives
implementations more room to do the right thing.

Thanks for your comments!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Mon, 15 Jan 2007 19:23:51 +0100

> fallback to avoid spoofed responses, at least in some cases).

Hi Florian,

I don't think RFC 1123 is within the scope of DNSEXT! We could insert
something non-normative, but I'm unsure what it would achieve.

> for instance, nor do they use random source ports, at least on typical

I'd be inclined to say that anything we care to recommend for a full
resolver would also go for a stub resolver. The only difference, according
to Olafur, is that a stub resolver can only talk to specified other servers,
and not to the world.

This point has been flagged as 'TBD' in the draft. 

Btw, some stub resolvers don't even use random IDs...

	Bert

---

From: Florian Weimer <[email-masked]>
Date: Mon, 15 Jan 2007 21:40:12 +0100

> something non-normative, but I'm unsure what it would achieve.

RFC 1123 updates RFC 1034 and 1035 (in section 6.1), and this part is
certainly in scope.  Actually, it's been updated before (at least de
facto, if not explicitly).

> Btw, some stub resolvers don't even use random IDs...

Yeah, I know, and I really wonder if it's worth going through the
trouble of fixing them.

---

From: bert hubert <[email-masked]>
Date: Mon, 15 Jan 2007 22:06:56 +0100

> RFC 1123 updates RFC 1034 and 1035 (in section 6.1), and this part is

Not sure if there is reciprocity though.

> Yeah, I know, and I really wonder if it's worth going through the

It is a far less explored thing - I think XP w/o service packs still uses
the ID 1, and 2 for any second simultaneous query. So my feelings are it
might be worth while to also mention stub resolvers as they receive very
little attention.

	Bert