Re: [dnsext] Re: Time-line for forgery resilience phase #2

[bert hubert <[e-mail]>]

Ok, this is somewhat of a tricky post since my own draft is among the ones
circulated. Additionally, some of the criticism I voice below applies
to the original forgery-resilience draft as well.

So take the below with more than a single grain of salt.

Sadly it appears we have not found the magic bullet, where magic bullet is
defined as a clear solution that can help us quickly. This rules out
anything that takes a lot of parties and time to deploy, or anything that is
more of a 'strategy' than a clear cut solution.

0x20 is nice, but breaks some stuff. Repeating queries is nice but breaks
some stuff. Determining if we are under attack is nice, but is a DoS vector
in some circumstances. Getting smart with disregarding parts of answers is
nice, but is not a perfect solution, plus might break some stuff. Etc etc.

Summarising, I think the current state of affairs does not allow us to write
a draft that recommends full solutions. Sadly, the best we can do right now
is standardise things that will give implementors the tools to implement
working strategies, strategies which are unkown right now.

There is some room for a concise document outlining simple things that help
a lot though.

Looking at the drafts below:

> At this point we have following drafts submitted:
>  http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt

Describes a number of valuable strategies, and mandates some others.
Unsure if it would reach consensus.

>  http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt

Outlines a lot of theory. Reads like an academic paper. Does not mandate
anything, or at least not in capital letters.

>  http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt
>  http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00

Both of these provide a way to add more entropy to a query, making it far
harder to spoof answers. One of these drafts uses a new record type, the
other (mine) a new EDNS0 option. Jim Reid did a great job finding a novel
and very hackish way of stuffing in said entropy.

The interesting thing about the above two drafts is that they only provide a
portal which can be used to develop further spoofing resilience. The
strategy of how to use these methods is left up to the caching nameserver
implementations, and this strategy is therefore free to evolve over time.

>  http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt

I find this draft to be concise, and it provides a nice mix between theory,
recommendations and exhortations. 

>  http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

0x20 is an impressive hack, but does not provide any protection for
numerical domains like '123.', and only two bits for '123.nl'. In this
sense, it is a very limited measure - as it leaves TLDs especially
vulnerable.

What would be good is to slip in somewhere that all responding
implementations MUST do a bitwise copy of the request name. Implementations
are then free to act on the liberty they've gained to assume that complying
responders will do a proper copy.

Summarising, I'd prefer to focus our attention on: 

	1) Wouter's document, since it is brief and has the potential to reach
	consensus.

	2) One of the two ways to add entropy to queries (aleatoric,
	   edns-ping)

An optimum might be reached if Wouter's document would contain a line like
'responders MUST perform a bitwise copy of the query name'. This would open
the door over time for people to rely on 0x20.

Kind regards,

Bert

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

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