Re: [Asrg] DNS over SCTP

[Douglas Otis <[e-mail]>]

On May 28, 2009, at 9:45 AM, David Conrad wrote:

> On May 28, 2009, at 5:47 AM, Alessandro Vesely wrote:
>> I don't trust the data because it is signed, I trust it because the  
>> signature proves that it originated from the authoritative server.
>
> Not quite.  The signature over the data proves that the holder of  
> the private key has signed the data.  The origin of that data then  
> becomes irrelevant.

This discussion started by describing how an authorization protocol  
might utilize macros embedded within a DNS cache to stage relatively  
free DDoS attacks, all of which would be made worse by DNSSEC.   
Preventing DNS poisoning was also a concern expressed, which is likely  
to go hand in hand with the DNS enabled attack.  Since DNS is normally  
connectionless, security solutions like SSL have been dismissed.    
While DNSSEC may protect against data corruption, such protection  
depends upon the thorny problem of verifying a key will be solved in a  
practical and politically acceptable manner.  This protection also  
requires authoritative servers to rapidly adopt DNSSEC without also  
confronting other insurmountable deployment issues.  Fool me once,  
shame on you.  Fool me twice...

>> Therefore, if I'm connected with the authoritative server over a  
>> trusted channel, I can trust the data even if it isn't signed.
>
> Not really.  You are relying on the fact that the authoritative  
> server and (potentially) the channels it uses to communicate to the  
> originator of the data have not been compromised.

Assume SCTP becomes generally available as a preferred transport for  
DNS.  If so, an ability to corrupt DNS information would be greatly  
reduced, whether data is signed or not.  In addition, SCTP can safely  
carry larger signed results without the DDoS concerns that will exist  
for either TCP or EDNS0 over UDP.  Deploying DNS on SCTP should be  
possible in parallel with the DNSSEC effort.

>> By induction, if a resolver only uses either signed data or trusted  
>> channels, I can trust it.
>
> A trusted channel is superfluous when the data is signed.

Receiving signed data represents just a fraction of the challenges  
facing DNSSEC. :^(

>> The limitations in TCP or SCTP security stem from an attacker's  
>> ability to compromise one or more routers, so as to either tamper  
>> with the packets on the fly, or redirect them to some other host.  
>> That's much more difficult than forging the source address of an  
>> UDP packet, though.
>
> True, but object security removes even the residual risk of channel  
> compromise (e.g., a compromised router).
>
> However, pragmatically speaking, I suspect it is going to be much,  
> much easier to get DNSSEC deployed than it would be to get every  
> router/firewall/NAT manufacturer and network operator to support/ 
> deploy SCTP, not to mention getting every DNSSEC server to support  
> DNS over SCTP.

While TCP represents a possible fall-back method whenever UDP  
overflows, TCP is not assured.  Instead of seldom, low prevalence  
might better describe TCP use in DNS.  In addition, DNS servers prefer  
UDP over TCP when resources become scarce.  TCP produces greater  
latency, requires more back and forth exchanges, and strands resources  
whenever confronting spoofed connection attempts.  While EDNS0 allows  
UDP to carry larger signed packets, this also increases UDP's exposure  
to increased reflected attacks that leverage the brute strength of DNS.

On the other hand, SCTP reserves resources until a request is  
confirmed by a returned cookie, which also allows data to be exchanged  
sooner than would be possible with TCP.  Unlike TCP, SCTP carries  
chunks over multiple streams rather than non-delineated bytes over a  
single stream.  SCTP connections consume minimal resources and can  
sustain longer sparse associations.  SCTP also tunnels over UDP to  
provide compatibility with legacy NATs and firewalls.  SCTP might soon  
become popular with browsers due to its inherent improvements on  
security and performance over TCP.  A solid SCTP stack is now  
available in FreeBSD that has corporate friendly source licenses. :^)

If there is one lesson that should have been learned from the DNSSEC  
effort, resolving DNS problems will require dedicated long term  
planning.  Within the same timeframe as DNSSEC, SCTP has been able to  
provide reliable and safe transport.  You might be using SCTP whenever  
you make a phone call or watch your TV.  It seems that the telephone,  
more than the Internet, is what people expect to just work.

-Doug