Re: DNS over SCTP

[Alessandro Vesely]

AJ Jaghori wrote:
This is a common misconception.  DNS over SCTP will not solve 90% of the 
problems!


Why?

Attackers are able to guess what DNS queries an SMTP server would put 
as a consequence of a client connection. Even after the Kaminsky fix, 
that leaves room for brute force attacks. If queries were run over 
TCP, the additional requirement to hijack a TCP connection would 
reduce the probabilities enough, even for today's botnets. Thus, using 
TCP would solve those security issues. (Is that 90%?) It would 
introduce some inefficiency, though. (More than DNSSEC?)


SCTP provides for several streams over a single connection, streams 
are asynchronous with one another like UDP packets, but are reliably 
connected and secured like TCP streams. With decent keep-alive 
directives, that would allow a client to be connected with a pool of 
relevant resolvers, thereby avoiding the inefficiencies that TCP would 
introduce.


On Thu, May 28, 2009 at 10:16 AM, Alessandro Vesely > wrote:


Stephane Bortzmeyer wrote:

   It seems that DNS over SCTP would solve 90% of the problems with 10%
   of the efforts and resources required to implement DNSSEC. However,
   I hear more often about the latter than the former. How come?


   I've read this message via the IETF general mailing list and so I
   missed the beginning. In what way can you compare DNSSEC (which
   provides object security) and SCTP or TCP (which provide a better
   channel security for DNS)?


The discussion was about how to get rid of the threats illustrated,
e.g., in Kaminsky, D.: "It’s the end of the cache as we know it."
In: Black Hat conference (2008). Online at http://www.doxpara.com/DMK_BO2K8.ppt

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[AJ Jaghori]

This is a common misconception.  DNS over SCTP will not solve 90% of the
problems!


On Thu, May 28, 2009 at 10:16 AM, Alessandro Vesely  wrote:

> Stephane Bortzmeyer wrote:
>
>> It seems that DNS over SCTP would solve 90% of the problems with 10%
>>> of the efforts and resources required to implement DNSSEC. However,
>>> I hear more often about the latter than the former. How come?
>>>
>>
>> I've read this message via the IETF general mailing list and so I
>> missed the beginning. In what way can you compare DNSSEC (which
>> provides object security) and SCTP or TCP (which provide a better
>> channel security for DNS)?
>>
>
> The discussion was about how to get rid of the threats illustrated, e.g.,
> in Kaminsky, D.: "It’s the end of the cache as we know it." In: Black Hat
> conference (2008). Online at http://www.doxpara.com/DMK_BO2K8.ppt
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Francis Dupont]

 In your previous mail you wrote:

=> I keep this because your answer is not about this...

   > I don't understand your argument: it seems to apply to UDP over SCTP  
   > but here we have SCTP over UDP.  BTW the easiest way to convert DNS  
   > over UDP into DNS over SCTP is to use an ALG (application layer  
   > gateway) which in the DNS is known as a caching server (such servers  
   > are already used to provide IPv4/IPv6 transport conversion).
   
   The goal is to apply the SCTP protocol as a means to better protect  
   DNS from source spoofing, resource exhaustion, reflected attack  
   exploitation, and increased latency.

=> not only this is very arguable (for instance about the resource
exhaustion) but no hop-by-hop/channel security, even something as
strong as TSIG, can provide what we need, i.e., end-to-end/object
security (*).

Regards

francis.dup...@fdupont.fr

PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

Paul Wouters wrote:

On Fri, 29 May 2009, Alessandro Vesely wrote:

It's what the patch has reinforced. SCTP is more secure than the 
patched bind, yet easier than DNSSEC.


where easier means "update all the root and TLD servers and load balancers
and what not to support DNS over SCTP. While DNSSEC is supported *right 
now* on that infrastructure. I would not call that "easier" at all.


There are a few acceptations of "easier" that characterize DNS over 
SCTP vs DNSSEC:


* it can be retrofitted, i.e. less software changes,
* it needs no signatures, i.e. no upgrades of original data,
* it uses no cryptography, i.e. more performance, and no PKI.

At any rate, using one solution does not preclude the other one, and 
two are better than one.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Douglas Otis]

On May 29, 2009, at 7:33 AM, Francis Dupont wrote:

I don't understand your argument: it seems to apply to UDP over SCTP  
but here we have SCTP over UDP.  BTW the easiest way to convert DNS  
over UDP into DNS over SCTP is to use an ALG (application layer  
gateway) which in the DNS is known as a caching server (such servers  
are already used to provide IPv4/IPv6 transport conversion).


The goal is to apply the SCTP protocol as a means to better protect  
DNS from source spoofing, resource exhaustion, reflected attack  
exploitation, and increased latency.  SCTP in any form does not  
prevent deployment of DNSSEC.  SCTP might even better facilitate  
DNSSEC than EDNS0.  Use of DNS on SCTP, even when tunneled over UDP,  
should be explored.  The issues related to DDoS risk related to cached  
macros were presented to various DNS WGs and forums.  Unfortunately,  
this DNS issue earned little respect from the proponents of the  
protocol using macros and extensive record chaining.  The prevalent  
response was to declare DNS broken by pointing to other aspects of DNS  
at risk.  SCTP seems a reasonable solution in the face of this  
neglect.  Problems are likely to grow much faster than adoption of  
DNSSEC.  In fact, adoption of DNSSEC may make some aspects of DDoS  
exploitation worse.


-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Masataka Ohta]

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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Mark Andrews]

In message <4a20539e.3070...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Paul Wouters wrote:
> 
> > DNSSEC involves no certificates and no certificate authorities. You know
> > this.
> 
> As is documented in the paper of David Clark;
> 
>http://portal.acm.org/citation.cfm?doid=383034.383037
>These certificates are principal components of essentially all
>public key schemes, except those that are so small in scale that
>the users can communicate their public keys to each other one to
>one, in an ad hoc way that is mutually trustworthy.
> 
> certificates are principal components of DNSSEC, a large scale
> public key scheme.
> 
> Not calling intermediate certificates between zones certificates
> does not change the reality that DNSSEC involves certificates.
> 
> >> Though there seems to be some confusion that DNSSEC security were
> >> end to end
> 
> > It is.
> 
> See the paper above to see why DNSSEC is NOT end to end.
> 
> Of cource, you may argue against David Clark, but, do so with
> reasons.

In a general PKI you need a third party to validated the
name to certificate mapping because there is not natual
method to do this.

With DNSSEC the naming authority is the introducing authority.
This is where DNSSEC differs from a general PKI infrastucture.
This is also what make DNSSEC a better as a PKI for domain names.

Mark

>   Masataka Ohta
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Masataka Ohta]

Paul Wouters wrote:

> DNSSEC involves no certificates and no certificate authorities. You know
> this.

As is documented in the paper of David Clark;

   http://portal.acm.org/citation.cfm?doid=383034.383037
   These certificates are principal components of essentially all
   public key schemes, except those that are so small in scale that
   the users can communicate their public keys to each other one to
   one, in an ad hoc way that is mutually trustworthy.

certificates are principal components of DNSSEC, a large scale
public key scheme.

Not calling intermediate certificates between zones certificates
does not change the reality that DNSSEC involves certificates.

>> Though there seems to be some confusion that DNSSEC security were
>> end to end

> It is.

See the paper above to see why DNSSEC is NOT end to end.

Of cource, you may argue against David Clark, but, do so with
reasons.

Masataka Ohta


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Paul Wouters]

On Fri, 29 May 2009, Masataka Ohta wrote:


Though there seems to be some confusion that DNSSEC security were
end to end


It is.


, below is an excerpt from an authentic document by David
Clark on how PKI, including DNSSEC, involves certificate authorities


DNSSEC involves no certificates and no certificate authorities. You know
this.

Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Paul Wouters]

On Fri, 29 May 2009, Alessandro Vesely wrote:

It's what the patch has reinforced. SCTP is more secure than the patched 
bind, yet easier than DNSSEC.


where easier means "update all the root and TLD servers and load balancers
and what not to support DNS over SCTP. While DNSSEC is supported *right now*
on that infrastructure. I would not call that "easier" at all.

Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

David Conrad wrote:
Given that it is pretty easy to predict a subset of the queries a 
given server will issue in a give time frame, using SCTP can improve 
reliability better than adding another 32bit random number.


1) It isn't easy


What did your mail server look up after receiving this message?


2) That's not what DNSSEC does (if that's what you're implying).


It's what the patch has reinforced. SCTP is more secure than the 
patched bind, yet easier than DNSSEC. (Or, if you prefer to avoid 
SCTP, it is less secure than DNSSEC, and more difficult than patching 
bind.)


This is why dnscurve is just an academic experiment that can never 
leave the lab for the real world.
IMHO, avoiding to base the Internet on an encumbered algorithm is 
another good reason :-/

Huh?  What are you talking about?


http://en.wikipedia.org/wiki/ECC_patents
https://datatracker.ietf.org/ipr/1154/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

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.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[David Conrad]

Alessandro,

On May 29, 2009, at 12:09 AM, Alessandro Vesely wrote:

One has to trust each cache!


With DNSSEC, you don't have to trust the cache since the only thing  
the miscreants who compromise the cache can do is the functional  
equivalent of removing the entry from the cache.


Given that it is pretty easy to predict a subset of the queries a  
given server will issue in a give time frame, using SCTP can improve  
reliability better than adding another 32bit random number.



1) It isn't easy
2) That's not what DNSSEC does (if that's what you're implying).

This is why dnscurve is just an academic experiment that can never  
leave the lab for the real world.
IMHO, avoiding to base the Internet on an encumbered algorithm is  
another good reason :-/


Huh?  What are you talking about?

Regards,
-drc


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Francis Dupont]

 In your previous mail you wrote:

   Shouldn't be difficult. I'm not much into either technology, but since 
   SCTP can be tunneled through UDP, it should be possible to retrofit 
   SCTP adoption onto an existing DNS implementation. On an OS that 
   provides SCTP natively, a module inserted between the DNS daemon and 
   its UDP sockets may operate the UDP/SCTP conversion when the remote 
   hosts support it.

=> I don't understand your argument: it seems to apply to UDP over SCTP
but here we have SCTP over UDP. BTW the easiest way to convert DNS over
UDP into DNS over SCTP is to use an ALG (application layer gateway)
which in the DNS is known as a caching server (such servers are already
used to provide IPv4/IPv6 transport conversion).

Regards

francis.dup...@fdupont.fr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP (was: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: a Critical Review

[Francis Dupont]

 In your previous mail you wrote:

   I thought TCP was the default when the UDP message size is not enough. 

=> with EDNS0 this is a bit more complex but IMHO this is the idea.
Note the recommended "connection management" (RFC 1025 4.2.2) suggests
multiple queries/responses too.

   That's, AFAIK, the only advantage of TCP over SCTP: it's already in 
   place and ready. (Yes, one needs to run firewalls and all that stuff.)
   
=> this is not a new idea but today no server or resolver implementation
supports DNS over SCTP.
I have a lot of sympathy for SCTP but for DNS we need a transaction
oriented transport, i.e., something more secure than simple stateless
query/response over UDP but without the overhead of opening and closing
TCP connections. This is a very old idea, cf. RFC 955, but as far as
I know this is still an open problem. If I am wrong (I'd like to be :-)
please request a BoF in the transport area ASAP!

   > A single SCTP connection can support thousands of simultaneous streams,
   
   I agree SCTP is better, and it's been around for nearly a decade now. 

=> IMHO it is far less than 10 years but arguing about this point is
out of topic.

   Yet, for those who miss it, good old TCP allows, say, a client to hold 
   a couple of connections to its favorite resolver in order to avoid 
   many of the threats illustrated by Kaminsky...
   
=> TCP is very expensive in terms of resources for the server and
TCP is still vulnerable to in-the-path attacks.

   > There is also OS support for UDP 
   > tunneling of SCTP when supporting legacy NATs and firewalls.  Until 
   > there is an significant incentive to make DNS more robust, use of SCTP 
   > is likely to remain just a good and under appreciated option.
   
   It seems that DNS over SCTP would solve 90% of the problems with 10% 
   of the efforts and resources required to implement DNSSEC. However, I 
   hear more often about the latter than the former. How come?
   
=> DNSSEC is the only available solution which solves the problems.
Others are not available (no specification published in a standard
track RFC or simply unfeasible) or don't address the problems
(hop-by-hop security for instance, when end-to-end is needed).
Both TCP and SCTP are in the others today...

Regards

francis.dup...@fdupont.fr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Paul Wouters]

On Fri, 29 May 2009, Alessandro Vesely wrote:

transport security is pretty meaningless in the DNS world which operates 
using a distributed caching system.


One has to trust each cache!


Your solution to protect the DNS is "just trust everyone"?

Given that it is pretty easy to predict a subset 
of the queries a given server will issue in a give time frame, using SCTP can 
improve reliability better than adding another 32bit random number.


The source port randomization patch is not DNSSEC. DNSSEC is much more then
a 32bit random number. Please read the RFCs.

Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Michael Tüxen]

On May 29, 2009, at 12:23 PM, Alessandro Vesely wrote:


David Conrad wrote:
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.


Shouldn't be difficult. I'm not much into either technology, but  
since SCTP can be tunneled through UDP, it should be possible to  
retrofit SCTP adoption onto an existing DNS implementation. On an OS  
that provides SCTP natively, a module inserted between the DNS  
daemon and its UDP sockets may operate the UDP/SCTP conversion when  
the remote hosts support it. Then, it would just discard spurious  
incoming UDP packets, and manage keep-alive settings for SCTP  
connections. It can work on a separate host or firewall, without  
even recompiling the DNS daemon.
On FreeBSD/MacOS X you can just code against the normal SCTP socket  
API and
set a sysctl that outgoing associations should be initiate via SCTP/ 
UDP/IPv[46].

For incoming associations everything is done automatically.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

David Conrad wrote:
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.


Shouldn't be difficult. I'm not much into either technology, but since 
SCTP can be tunneled through UDP, it should be possible to retrofit 
SCTP adoption onto an existing DNS implementation. On an OS that 
provides SCTP natively, a module inserted between the DNS daemon and 
its UDP sockets may operate the UDP/SCTP conversion when the remote 
hosts support it. Then, it would just discard spurious incoming UDP 
packets, and manage keep-alive settings for SCTP connections. It can 
work on a separate host or firewall, without even recompiling the DNS 
daemon.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

Paul Wouters wrote:

On Thu, 28 May 2009, Alessandro Vesely wrote:

The limitations in TCP or SCTP security stem from


transport security is pretty meaningless in the DNS world which operates 
using a distributed caching system.


One has to trust each cache! Given that it is pretty easy to predict a 
subset of the queries a given server will issue in a give time frame, 
using SCTP can improve reliability better than adding another 32bit 
random number.


This is why dnscurve is just an 
academic experiment that can never leave the lab for the real world.


IMHO, avoiding to base the Internet on an encumbered algorithm is 
another good reason :-/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Masataka Ohta]

Douglas Otis wrote:

> While DNSSEC may protect against data corruption,

So does TCP, UDP or SCTP checksum.

A problem is that such protection does not valid over a chain of
certificate authorities or caching servers.

> such protection  
> depends upon the thorny problem of verifying a key will be solved in a  
> practical and politically acceptable manner.

If the protection by a chain of untrustworthy certificate authorities
of DNSSEC is practically acceptable, a protection by a chain of
untrustworthy caching servers of plain old DNS is also practically
acceptable. Moreover, plain old DNS is already practically accepted.

Though there seems to be some confusion that DNSSEC security were
end to end, below is an excerpt from an authentic document by David
Clark on how PKI, including DNSSEC, involves certificate authorities
of third parties.

http://portal.acm.org/citation.cfm?doid=383034.383037
Public-key certificates
An important role for a third party occurs when public key cryptography
is used for user authentication and protected communication. A user can
create a public key and give it to others, to enable communication with
that user in a protected manner. Transactions based on a wellknown
public key can be rather simple two-party interactions that fit well
within the end to end paradigm. However, there is a key role for a
third party, which is to issue a Public Key Certificate and manage the
stock of such certificates; such parties are called certificate
authorities. The certificate is an assertion by that (presumably
trustworthy) third party that the indicated public key actually goes
with the particular user.


So, though communication between an end user and a certificate
authority can be end to end, the entire system of PKI is not.

Masataka Ohta


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[David Conrad]

Doug,

On May 28, 2009, at 2:36 PM, Douglas Otis wrote:
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.


If you're talking about the 'who signs the root key' political  
problem, I would note there is already an alternative.  Folks who  
don't trust whoever signs the root can simply include the trust  
anchors from the IANA ITAR (http://itar.iana.org/).  Yes, this means  
managing (many) more trust anchors than the single root anchor, but if  
you're that worried that the Men In Black might muck with the root  
KSK, you probably prefer to verify what IANA put into the root is  
valid by hand anyway.


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...


If there are insurmountable deployment issues, then it might be worth  
raising them in the DNSEXT working group so we can all stop wasting  
our time trying to deploy DNSSEC.


Assume SCTP becomes generally available as a preferred transport for  
DNS.


"First, boil the ocean..."

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.


I have no objection to anyone proposing DNS over SCTP and would agree  
there are benefits.  I am simply saying that channel security (such as  
DNS over SCTP) does not actually protect what matters, the data that  
is returned.  Specifically, if a device in the SCTP connection path is  
compromised and the data is not signed, you lose.  If the data is  
signed, it doesn't matter how you get the data or how hostile the path  
is.  Getting that data via SCTP would be fine.  But so would UDP, TCP,  
sneakernet, or IP over Carrier Pigeon.


Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Douglas Otis]

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

Re: DNS over SCTP

[David Conrad]

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.


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.


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.

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.


Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Paul Wouters]

On Thu, 28 May 2009, Alessandro Vesely wrote:


The limitations in TCP or SCTP security stem from


transport security is pretty meaningless in the DNS world which operates
using a distributed caching system. This is why dnscurve is just an
academic experient that can never leave the lab for the real world.

Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Michel Py]

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

Stephane Bortzmeyer wrote:

On Thu, May 28, 2009 at 04:16:31PM +0200,
 Alessandro Vesely  wrote 
 a message of 14 lines which said:


The discussion was about how to get rid of the threats illustrated,  
e.g., in Kaminsky, D.: "It?s the end of the cache as we know it." 


I know about Kaminsky bug, the WG "DNS operations" and "DNS
extensions" spent a lot of time on it. Please do not restate the
basics and explain why SCTP (or TCP) can be compared with DNSSEC
since, as I said, DNSSEC provides *object* security and TCP (or SCTP)
can only provide a limited *channel* security.


I don't trust the data because it is signed, I trust it because the 
signature proves that it originated from the authoritative server. 
Therefore, if I'm connected with the authoritative server over a 
trusted channel, I can trust the data even if it isn't signed. By 
induction, if a resolver only uses either signed data or trusted 
channels, I can trust it.


After all, cryptography just provides trusted channels of their own 
kind. The comparison involves the security features of those two kinds 
of channels.


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.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Stephane Bortzmeyer]

On Thu, May 28, 2009 at 04:16:31PM +0200,
 Alessandro Vesely  wrote 
 a message of 14 lines which said:

> The discussion was about how to get rid of the threats illustrated,  
> e.g., in Kaminsky, D.: "It?s the end of the cache as we know it." 

I know about Kaminsky bug, the WG "DNS operations" and "DNS
extensions" spent a lot of time on it. Please do not restate the
basics and explain why SCTP (or TCP) can be compared with DNSSEC
since, as I said, DNSSEC provides *object* security and TCP (or SCTP)
can only provide a limited *channel* security.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP

[Alessandro Vesely]

Stephane Bortzmeyer wrote:

It seems that DNS over SCTP would solve 90% of the problems with 10%
of the efforts and resources required to implement DNSSEC. However,
I hear more often about the latter than the former. How come?


I've read this message via the IETF general mailing list and so I
missed the beginning. In what way can you compare DNSSEC (which
provides object security) and SCTP or TCP (which provide a better
channel security for DNS)?


The discussion was about how to get rid of the threats illustrated, 
e.g., in Kaminsky, D.: "It’s the end of the cache as we know it." In: 
Black Hat conference (2008). Online at 
http://www.doxpara.com/DMK_BO2K8.ppt


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNS over SCTP (was: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: a Critical Review

[Stephane Bortzmeyer]

On Thu, May 28, 2009 at 03:04:19PM +0200,
 Alessandro Vesely  wrote 
 a message of 30 lines which said:

> I thought TCP was the default when the UDP message size is not
> enough.  

Well, in theory, it should be EDNS0 (standardized in the previous
century) but, in practice, it has deployment issues, like everything
which was invented after Jon Postel's death.

> It seems that DNS over SCTP would solve 90% of the problems with 10%
> of the efforts and resources required to implement DNSSEC. However,
> I hear more often about the latter than the former. How come?

I've read this message via the IETF general mailing list and so I
missed the beginning. In what way can you compare DNSSEC (which
provides object security) and SCTP or TCP (which provide a better
channel security for DNS)?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf