RE: Forgery Resistance phase #2

[Jesper G. Høy <[e-mail]>]

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: [e-mail] [mailto:owner-
> [e-mail]] On Behalf Of Ólafur Guðmundsson /DNSEXT
> chair
> Sent: Monday, July 28, 2008 5:54 PM
> To: [e-mail]
> Subject: Forgery Resistance phase #2
> 
> 
> 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 [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>



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