22 Mar
2010
22 Mar
'10
5:50 p.m.
I did some reading over the weekend on DNSSEC and an alternative proposal DnsCurve and my
conclusion is that
neither really allows us to trust a computer.
Problems with DNSSEC:
- Currently planned to use RSA-1024 which is reaching end of life so it will be a mess
when somebody factors
the root key. It should be noted that DNSSEC supports changing encryption algorithms but
these changes will have
to be installed in each implementing device.
- It sends a lot of data for a small request making it a ~100x DoS amplifier (If I can
find a connection which
allows me to send packets with a spoofed source IP, I can flush your box off of the
internet.)
- Companies don't want to give up the addresses of internal server names, address not
found errors should not
be able to be spoofed, and companies need to add and remove servers from their network,
taken together will lead
to complexity which is the enemy of security.
- The root key will be held by the US Commerce Department, this will introduce friction
with some governments.
It's a bit of a non-point though since it will be factorable with a few graphics
processors by the time DNSSEC is
finished rolling out.
- It is turning out to be very difficult to implement.
- Has the backing of Verisign and a handful of governments.
DNSSEC advantages:
- Has the backing of Verisign and a handful of governments.
- The idea of hierarchical signing of keys is attractive, it seems silly that a browser
would not be storing valid
keys and doesn't throw an exception when there are multiple valid keys to the same
URL.
Problems with DnsCurve:
- You cannot be sure that a domain hasn't been tampered with by a DNS cache admin.
Unfortunately this will not be
true for DNSSEC either until it is implemented all the way down to the browser level.
- Servers must have specific names because their public key is encoded in their name this
also limits the key size.
- It is just an extension of the existing DNS system, not a rethink of the design.
DnsCurve advantages:
- It is just an extension of the existing DNS system, not a rethink of the design.
- Simplicity. It only sits next to an existing DNS system and encrypts it's traffic to
and from the next one.
This will be an advantage for DNS admins who don't want to learn a whole new system.
- DnsCurve caches can communicate with legacy DNS servers and will detect DnsCurve support
on the fly.
- Can traverse badly configured firewalls which will be troublesome for DNSSEC.
- Uses elliptic curve cryptography which is not likely to be broken unless and until
quantum computing pans out.
- Provides confidentiality for DNS communication to and from the local cache. Not very
useful until we have
better treatment of http connections.
- Has the backing of D. J. Bernstein, the inventor of source port randomization as well as
tcp syn cookies and the DNS
server with the best security track record. He seems to know his stuff.
My conclusion:
DNSSEC is a great idea which should be part of SSL. However in the DNS system it gives a
bank (which should have at
least RSA-2048) the same security as a blog which honestly who cares if it's
redirected, someone will eventually figure
out and fix it. Signing of the root will have no effect until every website admin, every
ISP, and every cable/dsl router
changes over to DNSSEC, by then RSA-1024 will likely be a joke and since increasing the
size of the modulus would increase
the DoS amplification, the only sane answer will be to change encryption algorithms which
will be almost as bad as doing
the whole implementation over again (every website must reinstall, every ISP, every cable
modem, every browser...)
DnsCurve is a hack to keep things going another ten years and is written by a guy who is
very good at writing such things
(syn cookies). The encryption mechanism is theoretically very good although the
implementation needs review by more crypto
experts. It should be far easier to implement because under the hood it's plain old
DNS.
If we are trying to fix X509 then DNSSEC is a great idea and I am in favor of applying the
idea to X509 (or X510),
however if we are trying to fix DNS then I am in favor of DnsCurve because it looks like
it can actually be implemented
before the encryption algorithm is obsolete. If I was working on DNSSEC I would be looking
very closely at elliptic curve
and ask Bernstein for advice.
Given the current path of DNSSEC it appears there will be a lot of humor to be found as
the Commerce Department attempts to
sign the root.
I send this out to people who know more about it than me, so please correct me :)
Caleb
PS. You can get the benefits of DnsCurve now (for websites which support it) by setting
your dns server to the ip addresses
given at opendns.org
Story Henry wrote:
Thanks a lot Dan for the feedback. It is very helpful
for us to understand where things are going on the DNS front, as this is a core technology
we are building on.
Here is how I see the DNSSEC and the foaf+ssl stories converging.
DNSSEC solves the DNS security problem in a delegated fashion. As you say it is a
bootstrapper. As it is deployed the trust we can have in domain names, and hence in URLs
will grow dramatically. Not only will we be sure that we are talking to the right machine
(ip address to be correct), but it will be easier for people to deploy secure endpoints
such as https.
Foaf+SSL builds on that to create a web of trust for agents.
It is worth considering the difference between foaf+ssl and PGP, since you mention it
below.
PGP ties the identifier (an email address usually) to a public key. There is not 1 PGP
keyserver: there are many. These need to be synchronised somehow, and can easily get out
of date. If you feel like your private key has fallen in the wrong hands, you need to
notify all key servers. Furthermore your PGP web of trust is completely public. People can
20 years later look at the relations of who signed whose key to determine who knew whom.
And there is no way of removing a relationship.
FOAF+SSL on the other hand ties a public key to a WebId (a URL), which is tied to a
machine via DNS and soon DNSSEC. The key server is the web, which is based on the
internet, which is based on DNS. So we get all the good properties of DNS. If your private
key is compromised, you just need to update the information at your WebId, and remove the
public key information there. Updating the foaf+ssl key server is as easy as updating a
web page - and this is even more true now that the RDFa spec has been blessed by the W3C.
So one of my WebIds is http://bblfish.net/#hjs, which tied to a web page.
Secondly you can protect who can see the relations in your web of trust. You could
allow only friends to have access to your friend relations using HTTP access control. If
you discover that someone you thought was trustworthy no longer is, you can just remove
them from your Foaf profile. Again that is as simple as editing a web page. (try hunting
down all the people whose PGP profile you signed :-)
So FOAF+SSL gives us a web of trust but built on the most powerful naming system (key
server) in existence: the web. The web is built on DNS, which is has 25 years of
successful delegation, and with DNSSEC will give us another century :-)
Even better foaf+ssl uses X.509 which thanks to your work is going to end up being
secure. Even better we don't rely on the CA signing part of X.509 which was used to
'secure' servers, and so we don't suffer from the race to the bottom you
describe so well in your talks. In any case CA's never really attempted to certify
people. That would have been practically and legally infeasible.
So it seems to me that FOAF+SSL and DNSSEC are perfectly complementary. Of course we
still have to prove our case, and we have work to do building a lot more cool demos to
show how it can work... This is what we are buisy doing now.
Thanks again for your very helpful feedback.
Sincerely,
Henry Story
On 20 Mar 2010, at 23:17, Dan Kaminsky wrote:
My critiques against X.509 come down to the fact
that it's just not a
very good way to delegate trust. The roots are all equal and the
constraints don't work reliably.
DNS has 25 years of successful delegation. It has one root and it's
constraint system is very well designed. DNSSEC simply inherits this,
and adds crypto.
There is a significant question for DNSSEC, which is what do we put in
DNS now that we have a way to bootstrap trust?
Certs?
Cert fingerprints?
Public keys?
Public key fingerprints?
There are arguments for each. I'm leaning towards cert fingerprints
right now, but haven't entirely decided. DNS is not a high bandwidth
channel, it's a bootstrapper. So that's a constraint. Keeping
appcompat with existing X.509 architectures -- making DNSSEC an
exclusionary 'uber-root' -- has serious value too.
One thing I should make clear is I see value to the CA's.
Specifically, EV is the only way I see to overlay a closed, branded
namespace on top of DNS. This is a big deal.
The thing I want to make clear is that I am not a big fan of
distributed trust systems. I tend to see them unable to scale. I am
however even less a fan of tightly centralized trust systems. The
central provider doesn't even need to be malicious, just overburdened.
PGP doesn't work, not with web of trust and not with keyservers whose
records are constantly getting out of date.
Delegation works well, but only if the root of the delegation is
trustworthy. Well, the corollary to so many things breaking if DNS is
hacked, is that we really, really invest a lot of trust in the root
already. You guys know the old quote, a CA is only as strong as the
money it refuses to take?
The root, as an element of be state system, is an element of the
system that makes money itself. It's bureaucratic as all get out and
this is not a bug, but a feature. Its intransigence is a useful
defensive bulwark with no peer.
On Mar 20, 2010, at 2:44 PM, Henry Story <henry.story(a)gmail.com> wrote:
> Hi,
>
> Here are two issues with X509 that were hindrances for a solution
> like foaf+ssl to be deployed, but which can and are being fixed:
>
> 1. Client Side Certificate selection
> ------------------------------------
>
> Browsers currently do a very bad job of allowing the user to choose
> his certificate (Safari being the absolute worse). As a result I
> posted "Firefox Hackers Needed"
>
> http://bit.ly/cQ5f48
>
> earlier this week. @snej who is working at Google put up a picture
> of a solution for this in Chrome using a foaf+ssl certificate
> created by http://webid.myxwiki.org/
>
> http://bit.ly/azCXTU
>
> Vote for it!
>
> 2. Server side certificates
> ---------------------------
>
> One factor that people mention often with foaf+ssl is that the
> server has to have his own certificate. This means registration with
> a CA which is costly and tedious and it does not really solve the
> problems of server authentication as Dan Kaminsky shows ruthlessly
> in "Black Ops of PKI" http://bit.ly/4Uwb2K .
>
> To summarise his talk, server security is in a double bind:
>
> 1- Dan Kaminsky's DNS poisoning attack which is very well explained
> by Rick Van Rein's presentation "Cracking Internet: the urgency of
> DNSSEC" ( http://bit.ly/2darr8 view with FFox > 3.5 as it uses ogg
> video) means that a DNS easily be hacked in 6 weeks, and a lot of
> money poured into the wrong people's pockets. So there is a
> financial incentive to break DNS.
>
> 2. The solution of using https with X.509 public key cryptography's
> backing cannot work because there is a race to the bottom in the way
> CA's issue certificates. For enough money it is not that difficult
> to become God and to pretend you are anyone.
>
> Given the above DNSsec has become urgent enough, that it is being
> deployed.
>
> - verisign will put .com in July http://bit.ly/dyd54E
> - .org will be available in June http://bit.ly/abEJ28
> - .gov went dnssec in March 2009 http://bit.ly/bH27b0
> - The root will be signed July 2010 http://bit.ly/9YQMDJ
> - a map of dnssec deployment http://www.xelerance.com/dnssec/
>
> So listening to Dan Kaminsky you would think that he is against
> X509. Well certainly it could be improved a lot, but he is not quite
> as negative as one may think. X.509 with DNSsec seems to be
> something he thinks can work.
>
> What he told me after his CCC and HAR talks and what you can see in
> the last few minutes of the HAR talk "X509 considered Harmful"
http://bit.ly/2darr8
> is that once DNS is secure one could put the X509 (self signed
> even) certs into the DNS records. This would bypass the need for
> CAs. [ I hope I understood him correctly ]. I am not sure what needs
> to be done to make this possible with the browser vendors, but it
> would massively improve security on the web.
>
> As a result I have fait that the global situation on the internet
> will only make foaf+ssl solutions easier and more secure to deploy,
> enabling a completely distributed social network to emerge, free and
> without the spying, as Eben Moglen author of the GPL said so well
> recently http://bit.ly/brQmJz
>
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs