ietf
[Top] [All Lists]

Re: DNSSEC is NOT secure end to end

2009-06-04 23:32:49

On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote:

The problem is that the accuracy and integrity of DNSSEC is not cryptographically, but socially secure.

DNS over UDP is prone to port/transaction-id guessing, where cryptography could play a protective role. The risk of these values being guessed increases whenever NATs reduce port diversity, or operate in a predictable manner. Protocols such as SPF that embed macros into DNS, allow hundreds of transactions to be chained. The entire chain might result from the local-parts of a single email. These transactions can target otherwise uninvolved victims or evil domains. When an evil domain is the target of SPF transactions, attackers can discover the nature of the resolver. Afterwords, with only one transaction targeting the evil domain, and others targeting their victim, the guesswork for injecting poison is reduced, where even ACLs offer no protection. The growing speed of today's Internet makes this an ever growing concern.

While DNSSEC might prevent caches from being poisoned, EDNS0 creates new concerns also aggravated by SPF. Since the 512 byte DNS message size did not accommodate RSA signatures, EDNS0 is required to adjust message limits. EDNS0 allows bad actors to further leverage DNS transactions, such as those that might emanate from cached SPF records to initiate more than 20 TXT record transactions when a recipient evaluates a single email. The TXT records might be policy documents not intended for machine consumption or wildcard SPF records enumerating address authorizations for outbound MTAs. The flexibility sought by SPF has created a sizable list of concerns, where caution was often countered with distain for DNS.

It might have been better to have specified limits for EDNS0, such as a minimum message size of 1280 and a maximum at 1424, where transactions that don't comply are refused. UDP allows source spoofing, which could allow bad actors a means to create packet fragmentation by incorrectly setting message. If addition, when fragmentation does occur, DNS transactional-ids offer little protection for packet fragments that may contained unsigned information. DNS will need to be become pedantic about confirming information, perhaps also enforcing the use of checksums and message size.

While DNSSEC may not require channel security at some point when a trust anchor can be safely found, DNS over UDP remains a brute. When an SPF process sequence prematurely times out, rather than waiting for exponential back-off, SPF simply begins another sequence, ignoring congestion avoidance.

SCTP carrying either DNS or DNSEC packets would ensure DNS remains tame despite much of the abuse. Unlike TCP, SCTP does not commit resources without return of a cookie, but can start data exchanges sooner. SCTP can carry simultaneous DNS messages and can can keep a large number of sparse connections per port active. Perhaps recursive resolvers might be more responsive with SCTP than with UDP. Importantly, the source of abusive DNS behavior can be identified and thereby avoided. This is not true for either TCP or UDP.

-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf