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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf