DNSSEC

What happens before the handshake? How do we get the information needed to have a secure connection with the right server?

Fenrir does not use the common CA authorities, so where do we get the trust in this system?

The short answer is: it’s none of Fenrir’s business.

You only need to get 2 things in a secure way:

• The ip of the authentication server
• The public key of the authentication server.

And then you can connect in a secure way to a Fenrir service.

Since Fenrir does not handle this, we use DNSSEC, but any other secure, trusted service can be used.

The Trust

Managing the trust is difficult from a technical point of view, and even more from a political point of view: how do you group trust? Do we have to trust a single entity? Even if distributed, tlds represent countries, so how do you give control of a tld to a country? What countries do you recognize?

The problem was so complicated that I decided to completely avoid it. It is its own problem, and has to be resolved elsewhere.

It doesn’t mean we have to be limited by the old way of doing things: We can simply use an existing service that already is secure and has some sort of trust built into it, and implement things on top of it.

DNSSEC is such a service.

DNSSEC is secure (although there’s no secrecy, but we don’t need it), used worldwide, and lets us advertise the 2 things we need to give to everyone.

DNSSEC unfortunately has a problem with amplification attacks, but I see no other solution for now

The implementation

If you know something about minimaLT, you’ll find some of the ideas are similar. It’s not a coincidence, storing data in the DNS(SEC) system is an old idea, after all.

The first obvious solution is to use the A and AAAA records to store the ip address(es) of the authentication service(s), and put the public key in some TXT record.

There are different record types that could hold a public key, but they usually require a specific file format, while we want to be independent from anything like that, so we can just base64-encode the key in a TXT record.

Now we have a secure system that gives us the 2 things we need, we could stop here.

But if we stopped here, Fenrir would need a static port for UDP tunnelling.

Not good enough.

We could try using SRV records, but they have their limitations and anyway, we already have the solution: just encode it into the TXT record!

And now we have all information we need, and flexibility, too.

DNSSEC queries are big. And every record must have its own signature. This means that the DNS system will switch to TCP and slow down our handshake, or use the EDNS and put all of this in a huge udp packet.

Again, we already have the solution: put everything into the TXT record! No multiple signatures, and even with 4096-RSA keys we should stay inside a single ethernet packet.

Now the TXT record holds:

• The public key
• The (eventual) UDP port
• The ip addresses, so that authentication servers can have both load balancing and failover.

The Encoding

We put it in a single TXT record, so we are gaining a lot of previously wasted space due to the previous signatures (we only need one now), but can we do better?

Except from using compression, which would probably not save us much due to the not-so-compressible public key, we can change encoding algorithm.

Base64 is widely used, but it wastes a lot of space. How about base85?

Base64 wastes 1 bytes every 3 we want to encode. Base85 only one every 4. That can be a lot of saved space.

The result can now fit in a single UDP packet, and even if we use a 4096 RSA public key we should be under 800 bytes, with DNSSEC signatures

Conclusion

Now you have it: an independent, efficient way to store the data we need, and can be adapted to any other domain name system that will come along (like the Gnu Name System?).

-Luker