Re: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03
Dean Anderson
On Sun, 12 Oct 2008, George Barwood wrote:
> I have revised my draft at
>
> http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-03.txt
Did the WG decide to take on this draft? My understanding is that
'dnsext' in the name indicates a working group draft as opposed to an
individual submission, but the WG page does not list this draft. I must
have missed the discussion of whether the WG should take on this work. I
am against having the WG take on this draft.
Recommendation:
Anyone interested in avoiding cache poisoning should use port
randomization or TCP, or a combination of both. I suggest that a common
deployment scenario consists of a group of site-wide recursors serving
stub resolvers. If the stub resolvers are handled with UDP port
randomization, and the recursors use TCP, poisoning is limited to MITM
attacks. Only the site recursors need to be altered, and this
alteration is completely within the current DNS specifications. The
stub resolvers (which often do not cache responses) are speedilly
serviced by UDP as before. The recursors (which usually do cache
responses) get a lot of benefit from the overhead of TCP.
Comments on the draft:
There is no such thing as a "Kaminsky Attack". The attack to which the
draft refers was previously well known, as has been previously reported
with complete citations to previous analysis on this list, and on other
lists. DNS spoofing and cache poisoning was previously well-known to be
trivial, and accomplished in a fraction of a second on many popular name
servers; The attack is STILL trivial, and Kaminsky didn't discover
anything that made that attack easier. Kaminsky didn't discover ANYTHING
novel, nor ANYTHING that bears attachment of a new name. Rather, system
administrators unfamiliar with DNS vulnerabilities may have been
surprised to learn how easy it was to spoof DNS, but this fact is not
new. Continued use of the name "Kaminsky Attack" to describe a
previously known attack is a kind of contributory plagarism, since
Kaminsky cannot make claim to discovering the attack.
The draft asserts that by "repeating the query, additional entropy is
obtained". This assertion is false. Repeating the query either lowers
the entropy since it just doubles the number of valid outstanding query
ids that the attacker. If these QIDs are unique and not reused, there
are now only 32k pairs of QIDs (n * n-1; 65536 * 65535), which is less
entropy than would be found by ordinary port randomization, but doubling
the load on DNS. I have also reported that an attacker can arrange to
repeat the same query in an attempt to exploit a birthday problem.
Having the nameserver do this on its own initiative just makes the
attacker's job that much easier.
I am quite uncomfortable with the loose use of the term 'entropy' as a
justification that these tests make spoofing any harder. I am especially
dubious of the notion that one can inspect DNS payload data to somehow
get more 'entropy'.
It should also noted that nameservers may reply from a different IP
address than the one the query was sent to. This is fairly common on
multi-homed computers. One cannot add a check that the IP address is the
same.
The draft also notes some 'in-essential' information may be lost. There
is no 'in-essential' information in DNS, at least, no information that a
caching recursor can determine to be 'in-essential'. Any record that
exists in DNS must be considered to be meaningful to the site that
placed that record.
The draft also suggests randomly changing case of the query. DNS is not
case sensitive. Randomizing the case of the query and then checking that
the case remains the same in the response is a violation of DNS
protocol. Whether popular servers currently change case or not has no
bearing on whether other servers/implementers can assume this will or
will not happen.
In 3.4, prepending a random nonce and assuming a "referral is probable"
is a violation of protocol. The server that receives a query can send,
at its own discretion, a referral or perform recursion. Assuming what
the remote server might do when it has a choice is a violation of DNS
protoocol.
I also note that TCP suffers none of these particular poisoning
problems, and the 3way handshake is generally faster than the
multi-packet "convergence" contemplated in this draft.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>