Subject: Re: DNS over SCTP

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 20:01:45 +0200

Dean Anderson wrote:
> 
> TCP is used by many, if not all, resolvers to get large responses.
> 
> And I'm working on changes to DJBDNS dnscache that enable a
> configuration option to use TCP by default and fall back to UDP if TCP 
> is not available.

As that would increase security, I imagine that many operators will 
like to have it ready, just in case. However, I don't think many will 
enable that option, because of performance reasons. Enabling 
keep-alive is not practical, because slow queries would become a 
bottleneck. I haven't tried SCTP yet, but since it can have multiple 
streams, it should support keeping alive connections with the 
preferred resolvers. That would make the connection overhead 
imperceivable.

> See my NTIA comments on DNSSEC at
> http://www.ntia.doc.gov/dns/comments/comment027.pdf for details on the
> DDOS attack in DNSSEC.

Independently of who discovered the attack, Kaminsky's calculations on 
the probabilities of poisoning a server, given that the attacker knows 
exactly what the server is going to query, look correct. While 
guessing port and query id may succeed in with a workable probability, 
adding an SCTP TSN would drastically reduce them. I guess the very 
fact that this simple (possibly retrofittable) solution has not come 
out may be a further sign of conspiracy, if that's what you look for.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 30 May 2009 09:23:10 +0900

Dean Anderson wrote:

> The dispute on 'certificate' is over the definition of what
> 'certificate' means.

As I used the word 'certificate' with a reference, there is no
point to argue against me with terminology different from the
refereed paper.

Anyway, the definition of 'certificate' does not affect the
applicability of the paper to DNSSEC.

That is, DNSSEC is NOT secure end to end.

Security of DNSSEC depends on security of a chain of zones,
which are intelligent intermediate entities. If a zone in the
chain is compromised, DNSSEC is compromised, which is no
different from compromising cache in a chain of caching
servers/resolvers.

						Masataka Ohta