Subject: Forgery Resistance phase #2

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 28 Jul 2008 11:53:32 -0400

This message is sent in my role as chair with consent of my co-chair 
but without
his editing help, thus any mistakes in this message are mine and only mine.

The large volume of message over the last 2 weeks related to how to make DNS
safer made me think about "what are all the different possible approaches?"
Below is a list of ideas I have heard mentioned or thought off.

The list is supposed to be as complete as possible, if there is anything
missing feel free to bring it up.
Some of the ideas are stupid or do not make sense but are documented here
for sake of completeness.
Deployment of some of these ideas can be done real soon, others require
extensive software upgrades. The final solution selection may include more than
one ideas below as there is frequently not just one solution.

The goal of this email is that the WG is in a position to know that it is
selecting from a "complete set" of solutions When/IF the WG (or DNSOP WG)
decides that it should attempt to document/recommend more approaches than
what was covered in the FR-draft.

Covered in FR draft:
	Query ID
	Source Port
	Source Address

Randomness possibilities that originators have:
	Destination Address [1]
	Case games (like x20)
	Multiple identical questions [5]
	Repeat question [6]
	Spread question to number of nameservers. [7]
	Delay question [8]
	Time spaced repeated questions [9]
	"random" TCP query [11]

What Destinations can do to increase protection:
	More addresses: [10]
	DNSSEC

Protections that require both parties collaboration:
	TSIG
	DNS cookies
	TKEY + TSIG/SIG(0)
	SIG(0) 	Destination Protocol/port [2]
	Query name hacks (pre and post fixes) [3]
	EDNS ECHO [4]
	QCount > 1  [14]
	QClass top bit 8 redefinition [13]
	IPsec tunnels [12]
	IPv6 preference [15]

Steps that resolvers can take to protect them self:
	Forgery Detection
	and react to forgery attempts.

Steps that Operators of Authorative servers/zone owners can take:
	Deploy only current software
	Deploy DNSSEC
	Update ACL rules to reflect current recommended DNS port usage.

Comments:
[1] Destination Address: Many implementations go to first name server in an
	NS set all the time, some go to the one they know is closest or go
	to the one that they know has answered a query in the past, one they
	have an A record for, etc.
	From security point of view always selecting a random server is the
	best one. From an operating point of view this may/will cause more
	delays/errors. For high availability zones with short names having
	large NS sets is an possible source of randomness for example "." has
	13 A address this adds 3.5 bits of randomness for resolvers that use
	random selection. By expanding this to randomly select IPv4 and IPv6
	as transport for query another bit can be added.

[2] Destination Port: Another potential source for randomness is to reserve
	4 - 16 ports that DNS servers MUST listen on. 16 ports add 4 bits of
	randomness.

[3]  This relates to adding <foo.bar>.QNAME in query section or
	QNAME.<foo-bar> or even if QNAME is a.b.c to do
	a.<foo-bar>.b.c or a.b.<foo-bar>.c
	<foo.bar> is in this case has a known prefix in the first label
	that is registered with IANA so people can avoid it,
	if <foo-bar> is multiple labels the first label should encode
	how many bytes or labels to strip.

[4] EDNS Echo: A simple option to EDNS that instructs a server to copy back
	this option in the answer or the answer is not to be trusted.
	The contents of the option is random data unique to the query.

[5] In this case a resolver fires a number of identical questions off and
	expects to get the same number of identical answers.

[6] In this case the resolver repeats the question after getting an answer,
	it expects an identical answer.

[7] Spread question to a number of nameservers/recursive resolvers,
	expects to get back identical answers from all.

[8] Here the resolver waits for a short random time before sending the
	question but it is listening for answers from the time it forms
	the question.
	This is to detect forgery attack before sending the question.

[9] In this case the resolver sends queries that are spaced in time
	and it expects the answers to come back in the same order as sent the
	time between second and subsequent answers should approximate
	the transmission time.

[10] More designation addresses, larger NS sets potentially offer more
	protection as the client has more addresses to choose from.

[11] TCP queries are controversial as they require more state and overhead.
	Over the last few years we have seen TCP stacks optimized for handling
	large number of TCP connections thus the assumptions for not using TCP
	for DNS should be reexamined and requiring TCP port to be available on
	authorative servers will allow clients to fall back on TCP in
	specified situations.

[12] IPSEC: this is an option when there is strong relationship between two
	DNS entities, it is not clear how applicable this it is in the random
	resolver talking to random server.

[13] Right now about 4 classes are defined in the IANA registry. Use 
and deployment
	of new classes is difficult to say the least. For this reason it is tempting
	to steal some of these unusable bits into help protect the protocol.
	The proposal is to redefine the top 8 bits into a QID and servers would
	ignore these bits when checking class answer but echo them back in the
	answer's QCLASS.

[14] QCOUNT > 1 is currently not allowed but could be used to add 
randomness to
	the query if the second query is ignored in the answer processing
	but is copied into the answer.  There are number of different possibilities
	in how the randomness is expressed in the: label, QCLASS, QTYPE or all.

[15] IPv6 preference for queries, A resolver can cycle through many
	privacy address to increase source address randomization.

Sorry for the lack of attributions in this posting, if/when this becomes an
an ID that will be fixed.

	Olafur 

--
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: Alex Bligh <[email-masked]>
Date: Mon, 28 Jul 2008 17:59:27 +0100

> missing feel free to bring it up.

I contribute these for completeness without expressing an opinion
as to their validity or otherwise:

1. There seems a body of opinion on namedroppers that replacing stub
   resolvers by full recursive caching resolvers improves forgery
   resistance.

2. Under "Deploy DNSSEC" some commentators have said a long pole in the
   tent of deployability is signing the root, hence DLV and DLVPTR
   are relevant to the topic in that they could speed deployment of
   DNSSEC.

I think it's a useful list BTW. Another useful list would be to define
the problem space(s) being addressed as there was some debate about that
too.

Alex

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Jul 2008 19:18:07 +0100

At 11:53 AM -0400 7/28/08, Ólafur Gu©£mundsson /DNSEXT
>	and react to forgery attempts.

There is a glaring lack of footnote on that second one. I have heard 
multiple suggestions in the hallways this week. A bit more detail 
here would be appreciated.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 29 Jul 2008 06:06:10 -0400

At 14:18 28/07/2008, Paul Hoffman wrote:
>There is a glaring lack of footnote on that 
>second one. I have heard multiple suggestions in 
>the hallways this week. A bit more detail here would be appreciated.

yes it does, but this is a new area for DNS, suggestions are welcome.
The danger here is a that some possible fall backs might be worse
than doing nothing.

         Olafur

         Olafur

---

From: Jesper G. Høy <[email-masked]>
Date: Tue, 29 Jul 2008 15:28:21 +0200

I think my XQID suggestion (http://www.jhsoft.com/dns-xqid.htm), which by
the way seems like a even better idea in light of the Kaminsky bug, is
somewhere in your list already.

But I would be very interested to learn more about the other items.
Could you possibly expand the list with some links to more details on the
other ideas?

Thanks,
Jesper

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Ólafur Guðmundsson /DNSEXT
> chair
> Sent: Monday, July 28, 2008 5:54 PM
> To: [email-masked]
> Subject: Forgery Resistance phase #2
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Jul 2008 17:32:11 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> somewhere in your list already.

if we can amend the edns spec to require that for the XQID option, a reply
without XQID will cause the transaction to be repeated several times across
all of the zone's nameservers, with a different random UDP port and 16-bit
QID each time, then i will support the XQID proposal.  (this logic for
repeat-on-suspicion is more or less what we're recommending in 0x20, and
it's possible that if there are enough 0x20 bits available, then an XQID
could be made optional for that transaction.)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 30 Jul 2008 20:09:13 +0200

> could be made optional for that transaction.)

correct me if i'm wrong, but i think you might be confusing two
proposals here. XQID and the EDNS PING proposal. XQID appends entropy to
the actual query name, and shouldn't be downgradeable by leaving out
something (because then the answer wouldn't be the same as the query).

Using EDNS PING is 'cleaner' (it doesn't muck with the query), but would
need something like you ask for here.

Jelte

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Jul 2008 19:00:06 +0000

> need something like you ask for here.

yes, and i apologize for my confusion, i'm jittery from too much coffee and
too little sleep in the last few weeks.  PING with that modification to
EDNS's fallback would work, though i'm beginning to realize that the
requirement should be phrased as "each query transaction must be protected
by XYZ bits of high quality random entropy, which can be reached using any
combination of udp port number, query ID, DNS 0x20 bits, PING, or repeated
queries".  XYZ is probably about 50 if we want to rule out guessing
attacks.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 30 Jul 2008 21:28:35 +0200

Paul Vixie wrote:
>
> though i'm beginning to realize that the

I'm actually not too sure of whether a 'mix and match to your hearts
content' approach is what we should be trying to achieve here. Although
that might make debugging problems so insanely difficult that switching
to DNSSEC will be a relief :)

I do have two questions, that probably go for all the add-entropy proposals;

1. Do all recursive servers even have access to enough entropy? This
might not be a problem at all, or extra entropy could be arranged for
busy ones, but it might be worth thinking about in advance. For that
matter, what about dos attacks where the entropy pool itself is
attacked, is that possible? What would happen then?

2. Is it feasible to require (as a deployment consideration or
otherwise) that in setups where there might be multiple implementations
pretending to be one server, all implementations should have the exact
same feature set? Would we even want that?

Jelte

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Jul 2008 19:36:55 +0000

> to DNSSEC will be a relief :)

tkey+tsig, or dnssec+sig(0), or vpn, should be considered equivilent.  that
has been my basic gripe with bert's draft on forgery resilience -- it mandates
a specific method rather than offering a specific method and then mandating
that some method equivilent or superior to that method in strength be used.

> matter, what about dos attacks where the entropy pool itself is attacked,
> is that possible? What would happen then?

in my statement i called for "high quality randomness".  if you don't have
enough randomness, or if its quality is too low, then you can't speak dns.
(and, i expect that banks will test your RDNS strength before letting you
log in, assuming that this approach isn't already patented up the wazoo.)

> same feature set? Would we even want that?

i think we can strongly recommend, but not mandate, that all members of a
local or distributed dns cluster (whether authority or recursive or stub)
implement the same protections and options, but that in practice, stuff
will be wrong, there will be churn, there will be partial rollouts for
testing and QA, and thus it will always be nec'y for initiators to cope
with inconsistent responders.

---

From: bert hubert <[email-masked]>
Date: Wed, 30 Jul 2008 22:13:06 +0200

> busy ones, but it might be worth thinking about in advance. For that

I discussed this with Amit Klein, who I think can rightfully claim to be an
expert on DNS randomness, and he doesn't think it is a problem.

He suggests using block or streamcipher based pseudo-random generator,
seeded using 'real random'. 

Even if all excreted pseudo-random is observed from that point onward,
reverse engineering the state of the pseudo-random generator is equivalent
to breaking the cipher it uses, based on an unknown plaintext (the truly
random seed that is being encrypted over and over).

Amit does suggest rekeying every once in a while since AES performed by
software on known hardware leaks a tiny bit of information in the time it
takes to encrypt a block.

This last technique was discovered by Dan J. Bernstein btw.

Odd that :-)

	Bert

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