For some time, I've had this idea brewing for how the 'net would work
without DNS. Initially I was mostly thinking of how to get rid of the
dark side of the registrar business, but it appears that maybe it
could help with security in general too. It may not be feasible at
all, or I may have forgotten extremely crucial points. I'm not a DNS
guru, so bear with me and consider this as a thought experiment. This
is, however, a proposal for how the Internet could be made truly
decentralized, or acentric.
Made so, because it currently is very
centralized on at least two counts: the DNS is an inherently
hierarchical structure of authority; and so is the situation with the
SSL certificates used for securing websites. Let's start with DNS,
if you will.
Basically, the idea is to replace the current Domain Name System,
which is centralised in nature (even if subdomains can be delegated)
with a fully decentralised system with no central authority.
The point of current DNS is to map names to IP addresses in a unique
way. It currently works by registering a this name is managed by
such-and-such server, ask for details at such-and-such IP address
message. Of course, since there's only one namespace (or a limited
number thereof, if you consider that TLDs are different namespaces),
there needs to be a central authority to resolve conflicts, because
some names will be more popular than others.
I propose to start with a cryptographic key pair (think GPG key).
Anyone can create their key pair; we assume that it's extremely
unlikely for two people to generate the same keys, and that it's also
very hard for two people to generate keys with the same fingerprint.
By (being the only one) knowing the secret part of a key, I am the
authority on what can be signed with it. I could for instance sign
records that say that
www points to this set of IP addresses, and
smtp points to that other address. Within my area of authority,
which is to say within my domain. Which is identified by the
fingerprint of my key pair.
What do we have so far? A mechanism that allows in a decentralised
way to verify who's authoritative on the
F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more
probably
F55...3F5.some-tld. Now let's publish the signed records
on a decentralised peer-to-peer network. I'm not up to date with the
latest trends in that domain, but I think something like Gnutella or
Freenet would qualify, since it doesn't need central hubs but only an
initial list of nodes, and it does automatic discovery of new nodes.
Projects such as the
FreedomBox
(name likely to be changed) will probably help with that. Anyway,
when looking up
www.F55...3F5.some-tld, the resolver gets the signed
record (and the public part of the key) from the P2P network, checks
the signature, and uses the contents of the record to determine the IP
address. No central or delegated registry involved at any point.
Lesser risk of a single point of failure, which means better
resilience against outages. Also, a better resilience against
DNS-based censorship, be it promoted by non-democratic states or by
greedy corporations.
Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly
easy name to remember or transmit. But the string of hex could be
presented to the user in some other form easier to recognize for
people without geek super-powers. My favourite would be the
bibi-binary representation, but I'm told that the bubble-babble method
works equally well. It would still be unreasonable to expect people
to remember such names, and especially to type them into their web
browsers or e-mail agents. A possible solution to that would be to
use a short form, such as 144843F5 (or its bibi-binary equivalent),
complemented by a visual representation of the full fingerprint such
as the one SSH does. That pair could be displayed on business cards,
email signatures, glossy brochures, advertisements and so on, and
allow users to just type the strange word or flash the 2D barcode,
check that the funny picture matches (in case the strange word returns
several results), and get the website they want. Which they can of
course bookmark under a name they can remember, probably even the same
name that everyone else uses to bookmark that website. And nothing
precludes convenient directories mapping names to full URLs (like
search engines currently do) as long as users check that the visual
representation of the site they go to matches what they've seen
elsewhere.
That elsewhere could, of course, take advantage of the natural web
of trust that emerges in of GPG-using communities. If I'm directed at
a website whose key I don't immediately recognize, then I can see who
trusts that key to be legitimate (by checking the signatures), and who
trusts them, and so on. Ultimately, the decision is
mine to make,
and mine only. In any case, once I know what URL I want to visit, I
can be sure this DNS replacement will give me the right IP address (or
addresses). DNS servers replying with advertisement sites instead of
correct ones, and DNS-based filtering, will be things of the past.
Of course, having the right IP address only solves the attacks on the
DNS part. Eavesdropping can also happen by diverting traffic at the
IP level. But we have a trustable way to know information related to
a domain, so let's use it: the signed record can also contain the
fingerprint of cryptographic keys (SSL or SSH or whatever). So we can
be sure we're actually talking to the correct server, rather than to
some man-in-the-middle spy. With the same guarantees of correctness
as the ones for the DNS, backed by the web of trust and out-of-band
validation. Again, we get rid of the hierarchy of certification
authorities , some of which have been known for helping organizations
get at the (supposedly secret) data people exchange over the net.
To summarize: with this scheme, if I know the site I want to access is
F55...3F5, then I can be certain that a) I get the right IP address
for it and b) I'm actually talking to it. And nobody in-between
can intercept the traffic, if the site is properly administrated and
its private key is kept secure. And from the site admin's point of
view, there's no need to trust DNS registrars and SSL certification
authorities not to fool around with the data, or blackmail me into
paying increasing fees for keeping my URL working or my SSL key
certified. There's still the problem of the allocation for the IP
addresses themselves, but two major parts of the centralized and
hierarchical net can be gotten rid of.
There are proposals attempting to fix part of the problems already,
but they're incomplete.
DNSSEC
only solves the authentication of DNS records, not the centralisation
problem.
Monkeysphere aims at adding
a web of trust to the SSL certificates system, but the CA chain
problem seems to persist (although I must admit I'm not up to speed
with the actual details).
This is of course only a rough draft, full of technical considerations
yet certainly not exhaustive. I've thought about it though, and I
believe there are no theoretical problems with the implementation of
such a scheme (apart for the handling of expiration and revocations,
probably). The main obstacle to mass-adoption I can envision is the
UI part, and the entrenched habit of just typing a keyword into a
search engine and implicitly trusting its results, then blindly
trusting the website itself; but even if mass-adoption isn't reached,
I can't see anything wrong with giving those who want to be careful a
more secure Internet.
I travel pretty regularly, about 35% so far in 2010. When it goes wrong, travel can be exhausting, frustrating, complicated, stressful and even debilitating. I m always looking for ways to make my trips run more smoothly. On a recent flight to Taipei, I wrote down a few of the techniques which I ve successfully put into practice and found helpful. This is not an exhaustive list; I ve omitted a lot of the common and obvious tips I ve seen elsewhere.
A month or so ago, I published 
I today 
If you're not using ssh-agent to authenticate yourself to SSH servers, you should be. (i'm assuming you're already using PubkeyAuthentication; if you're still using PasswordAuthentication, ChallengeResponseAuthentication or KbdInteractiveAuthentication, fix that please). You should use ssh-agent for a number of reasons, actually, but the simplest is this: when you authenticate to a text-based channel on a remote server, you should never have to type anything about that authentication into the channel that will eventually be controlled by the remote server. That's because a malicious server could simply accept your connection as an anonymous connection and print out the exact prompt you're expecting. Then, whatever you're typing goes into the remote server instead of into your authentication scheme. and congrats, you just gave away the passphrase for your key. With ssh-agent, you talk first to your agent. Then, you talk to the server and your ssh client talks to the agent. Your keys and your passphrase are never exposed. the second reason is that the agent is a much smaller piece of code than the ssh client, and it doesn't talk to the network at all (unless you force it to). It holds your key and never releases it to querying processes; It even runs in a protected memory space so other processes can't peek at it. So if this protected, isolated agent is what holds your key, you're in much better shape than if a non-protected, larger, network-active process (the ssh client) has direct access to your secret key material. The third reason is that it's just more convenient -- you can put a key in your agent, and ask it to prompt you when its use is requested. you don't actually need to re-type your passphrase each time. you can just hit enter or type "yes". And if that scares you security-wise then you can put the key in for a limited period of time, as well. (btw, you should be using the ssh-agent that ships with OpenSSH, probably not the implementation offered by gnome, which 
One of the nice things that I've been involved with since starting
to work at ARM in Cambridge is setting up newer, faster machines to
help with the armel port. We have six machines hosted in the machine
room here now:
All of these machines are Marvell DB-78x00-BP development boards,
each configured with a 1GHz Feroceon processor (ARM v5t), 1.5GB of RAM
and a 250GB drive attached via SATA. They're nice machines, reasonably
powerful yet (as with many ARM-based machines) they draw very very
little electrical power even when working hard. These very boards were
used for a while by the folks at Canonical to help build the Ubuntu
armel port, but now we've got them.
In terms of configuration, these machines are not quite
fully supported in Debian yet, though. The kernels we're using are
locally-built, based on the Debian linux-source-2.6.32 package but
with a .config
(
I finally found the time to port the 
My comment form on my blog contains the following, right above the
<textarea> element where the text can be entered:
As this year's admin, I wrote up the following summary which has now been
posted at the 
Usually I like to monitor as much as possible. but unfortunately my cable provider does not allow to access the cable modem via SNMP, so I had to find a different way to retrieve at least some basic information. After a bit of googling I figured out how to access the web interface of the Scientific Atlanta modems. The model here is a EPC2203 - seems to work for various models, though.
These modems do not only provide access to the traffic within the cable network on their internal networking port (ever tried tcpdump on that?), but they also have their own IP (192.168.100.1). To be able to access the modem you should add something like
This morning, my laptop was stolen from my parked car while I was jogging. I do not want to make a big deal out of it.
Still, even though I am sure it was not targetted at my data (three other people at least were reporting similar facts in the same area), and the laptop's disk will probably just be reformatted, I am trying to limit the possible impact of my cryptographic identification being in somebody else's hands.
GPG makes it easy: I had on that machine just my old 1024D key, so it is just matter of generating a revocation certificate. I have done that, and uploaded it to the SKS keyservers - Anyway, here is my revocation certificate:
