Subject: [dnsext] [[email-masked]: Re: DNS over SCTP]

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 May 2009 10:32:40 +0200

This is related to the strategic discussions about object security
(DNSSEC) vs. improved channel security (cookies, EDNS ping). For once,
D. Otis is clear and non-confrontational so I forward his message
here.

Subject: Re: DNS over SCTP
From: Douglas Otis <[email-masked]>
To: David Conrad <[email-masked]>
Cc: [email-masked], Anti-Spam Research Group - IRTF <[email-masked]>, Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 17:36:30 -0700
List-Id: IETF-Discussion <ietf.ietf.org>

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: bert hubert <[email-masked]>
Date: Fri, 29 May 2009 12:50:20 +0200

> D. Otis is clear and non-confrontational so I forward his message

This has been discussed as far back as 2004, and no serious problems
with this idea have every been raised (as far as I can recall), except
for the very sparse deployment of SCTP, plus the likelihood of many
firewalls blocking this traffic.

The interesting thing is that DNS over SCTP with an authoritative
server for a resolver currently has only three clear operational
states:

 1) no response (timeout)
 2) error (icmp generated, or the equivalent of connection refused)
 3) works

There is unlikely to be a lot in between. This makes fallback rather
easy and unambiguous.

DCCP has also been raised as a transport mechanism.

    Bert

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 May 2009 16:37:57 +0200

In your previous mail you wrote:

=> and very far before RFC 955 section 3...

[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 May 2009 15:00:26 +0000

sctp won't stop "provider in the middle" attacks and so, while i agree that
it ought to be added as a DNS transport (solving certain problems UDP and
TCP each have) i don't consider it relevant to the DNSSEC problem space.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 May 2009 15:11:13 +0000

> From: bert hubert <[email-masked]>
> Date: Fri, 29 May 2009 12:50:20 +0200
> 

for interested readers, the most recent thread on this begins at:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01454.html

(noting that doug otis was also very much present in that discussion.)