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

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 15:04:19 +0200

Douglas Otis wrote:
>> Just using TCP would prevent most of the DNS poisoning attacks that 
>> Amir's paper reports.
> 
> TCP is prone to DDoS attack.  As such, TCP is seldom used with DNS.

I thought TCP was the default when the UDP message size is not enough. 
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.)

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

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 May 2009 15:15:09 +0200

On Thu, May 28, 2009 at 03:04:19PM +0200,
 Alessandro Vesely <[email-masked]> wrote 

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

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.

> 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)?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 16:16:31 +0200

> 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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 May 2009 16:23:25 +0200

On Thu, May 28, 2009 at 04:16:31PM +0200,
 Alessandro Vesely <[email-masked]> wrote 
 a message of 14 lines which said:

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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 May 2009 17:47:32 +0200

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 May 2009 12:38:56 -0400 (EDT)

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

---

From: David Conrad <[email-masked]>
Date: Thu, 28 May 2009 06:45:04 -1000

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

> 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  

A trusted channel is superfluous when the data is signed.

> 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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 May 2009 17:36:30 -0700

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

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

> Not really.  You are relying on the fact that the authoritative  
> server and (potentially) the channels it uses to communicate to the  

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.

> A trusted channel is superfluous when the data is signed.

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

>> That's much more difficult than forging the source address of an  
>> UDP packet, though.
>
> 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

---

From: David Conrad <[email-masked]>
Date: Thu, 28 May 2009 16:34:38 -1000

Doug,

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

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 29 May 2009 14:14:32 +0900

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 12:09:46 +0200

Paul Wouters wrote:
> 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 :-/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 May 2009 12:23:53 +0200

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.

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 29 May 2009 12:27:20 +0200

On May 29, 2009, at 12:23 PM, Alessandro Vesely 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. 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2009 09:28:29 -0400 (EDT)

On Fri, 29 May 2009, Alessandro Vesely wrote:

> 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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 May 2009 15:29:58 +0200

In your previous mail you wrote:

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

=> 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!

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

=> TCP is very expensive in terms of resources for the server and
TCP is still vulnerable to in-the-path attacks.

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

[email-masked]

---

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

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

---

From: David Conrad <[email-masked]>
Date: Fri, 29 May 2009 07:31:24 -1000

Alessandro,

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

Huh?  What are you talking about?

Regards,
-drc

---

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

>> reliability better than adding another 32bit random number.

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

> Huh?  What are you talking about?

http://en.wikipedia.org/wiki/ECC_patents
https://datatracker.ietf.org/ipr/1154/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2009 15:30:40 -0400 (EDT)

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2009 15:46:16 -0400 (EDT)

On Fri, 29 May 2009, Masataka Ohta wrote:

> end to end

It is.

> , below is an excerpt from an authentic document by David

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

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 30 May 2009 06:29:02 +0900

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

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.

> 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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 30 May 2009 10:09:54 +1000

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

	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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 May 2009 17:24:54 -0700

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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 30 May 2009 17:40:26 +0900

> 	With DNSSEC the naming authority is the introducing authority.

Read the paper.

Your attempt to modify the meaning of "the third party" does not
affect the following part of the paper and its consequences.

> 	This is where DNSSEC differs from a general PKI infrastucture.

Regardless of whether DNSSEC differs from a general PKI or not,
security of DNSSEC is not end to end.

						Masataka Ohta

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 May 2009 12:00:32 +0200

Paul Wouters wrote:
>> patched bind, yet easier than DNSSEC.
> 
> 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.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 30 May 2009 22:31:59 +0200

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

   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

PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 31 May 2009 08:27:07 +0900

> strong as TSIG, can provide what we need, i.e., end-to-end/object

Unless your meaning of end-to-end differs from that of David Clark,
the following argument of his paper is applicable to DNSSEC.

	http://portal.acm.org/citation.cfm?doid=383034.383037
	Rethinking the design of the Internet:
	The end to end arguments vs. the brave new world

	The certificate is an assertion by that (presumably
	trustworthy) third party that the indicated public key
	actually goes with the particular user.

	These certificates are principal components of essentially
	all public key schemes,

That is, security of DNSSEC involves third parties and is not end
to end.

> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

I'm afraid you don't know who David Clark is and how he is related
to the end to end argument.

However, all the people who are qualified to discuss end to end do
know him and his argument.

							Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Sun, 31 May 2009 23:44:17 +0200

> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

=> I added it because hop-by-hop and end-to-end can be ambiguous when
hops and ends are not defined. In the context of DNS intermediate
entities are the caching servers so even I agree your argument is
valid it doesn't apply to *this* interpretation of the term end-to-end.

Regards

PS: if you'd like to discuss about end-to-end arguments there is a
dedicated mailing list at IRTF. If you'd like to continue about the
trusted third parties as intermediate entities I believe the thread
you initiated is the best place.

---

From: Joe Baptista <[email-masked]>
Date: Sun, 31 May 2009 21:02:15 -0400

DNSSEC indeed violates the end to end principle.  It's simply that simple.
And it asks us to put our trust in the root a.k.a. ICANN.  I don't think
governments world wide are going to put their trust and faith in ICANN.  The
U.S. Government is the only government that has been bamboozled into
adopting DNSSEC into .gov infrastructure.

I wonder how President Obama would feel about handing over the keys to U.S.
Government infrastructure to a U.S. contractor.  I'd have trouble sleeping
at night if that was the case.

I've addressed this at length in my comments to the NTIA.

http://www.ntia.doc.gov/DNS/comments/comment034.pdf

If the U.S. government wants DNSSEC today then it must nationalize the
roots.  I don't even trust Vixie with the root.  I remember when he hijacked
the root with Postel.  Or as they put it "we were only running an
experiment".

In any case the new infrastructure campaign demands U.S. government roots be
set up to exclusively serve U.S. network infrastructure.

regards
joe baptista

p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.

http://dnscurve.org/

-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com

-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com

---

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Jun 2009 11:38:15 +1000

> p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.

	DNSCurve has exactly the same trust issues as DNSSEC does.
	You are trusting the parent to give you a secure introduction
	to the child.  The introduction is just encoded differently.

	Mark

---

From: Joe Baptista <[email-masked]>
Date: Mon, 1 Jun 2009 00:00:06 -0400

I disagree.  DNSCurve has nothing to do with trust.  It simply ensure the
system you are connected to is in fact the system that gives you the
answer.  DNSCurve addresses the UDP issues without the need for a root or
any other third party enjoying any degree of trust.

Totally different from DNSSEC.

regards
joe baptista

-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium

---

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Jun 2009 14:30:28 +1000

> any other third party enjoying any degree of trust.

	If you believe that I have a bridge to sell you.
 
> Totally different from DNSSEC.

	You can disagree all you want but it doesn't change the
	fact that DNSSEC and DNSCurve both have chains of trusts.
	The proponents of DNSCurve even say this.
	
	Note the chain of trust as described on
	http://www.dnscurve.org/tld.html/.

The root DNS servers can also be protected with DNSCurve. Once a
cache knows DNSCurve server names for the root servers, its packets
to and from those servers are protected, so it securely learns the
DNSCurve server names for .com and other top-level domains, so its
packets to and from the .com servers are protected, so it securely
learns the DNSCurve server names for nytimes.com, etc.

	Mark