Mon 12 Feb 2024

§Capability DNS

We have this nameserver that can provision TLS certificates with ACME using the DNS challenge, and expose a Cap’NP proto interface https://github.com/RyanGibb/eon/blob/main/bin/acme/capnp/service_api.capnp. We also have logic to tunnel Cap’NP over DNS https://github.com/RyanGibb/eon/tree/main/lib/transport, and indeed tunnel arbitrary data such as IP-traffic https://github.com/RyanGibb/eon/tree/main/bin/transport/tunnel. Two ideas we had relating to this were exposing a shell interface https://github.com/RyanGibb/eon/tree/main/bin/transport/sod over DNS and tunneling DNS traffic itself over DNS for query privacy a la Oblivious DNS https://github.com/RyanGibb/eon/tree/main/bin/transport/dodo.

I’ve had a look for any related work to ‘de-risk’ a paper. The most obvious is Signposts, which performs an ‘effectful’ name resolution to establish a communication channel through features of edge networks that break the end-to-end principle like NATs and proxies. It relies on DNSSEC to secure these names.

Certificate are typically automatically provisioned with purpose built ACME clients e.g. certbot and lego, or built-in application certificate provisioning like caddy and stallwart. The simplest challenge for most of them is HTTP/ALPN, but is limited in the deployment scenarios supported (e.g.. Support for the DNS challenge is typically done with DNS UPDATES / service-provider specific backends, which entails managing access controls to the DNS, often with no granular access control. Some custom nameservers offer granular access control for this purpose. However, Cap’NP provides us a mechanism to selectively expose domains to a service for solely the purpose of provisining a certificate, without having to run a local certbot. All that needs to be done for an application to support this is a lightweight language-agnostic Cap’NP client to request a certificate with a callback for renewal.

Once the nameserver gains knowledge of the services running on it, maybe we can start thinking about what can be done with that knowledge and e.g. exposing them over a VPN.

§Lenscap

Anil asked for instructions on how to deployment the ACME cert provisioning nameserver in our last meeting. To deploy Lenscap (Let’s Encrypt Nameserver Capability – we need a better name), build it according to https://github.com/RyanGibb/eon/#building.

Find the binary at _build/install/default/bin/lenscap or result/bin/lenscap (depending on if build with opam or nix).

On a machine with glue records for the nameserver for <domain> run:

$ lenscap --capnp-secret-key-file secret-key.pem --capnp-listen-address tcp:localhost:7000 --authorative <domain>

Or pass in a zonefile for <domain> with:

$ lenscap --capnp-secret-key-file secret-key.pem --capnp-listen-address tcp:localhost:7000 --zonefile <path>/<domain>

Get the root capability with:

$ cat root.cap

And provision a certificate with a client using:

$ ./lenscapc.exe <root.cap contents> <acme account email e.g. ryan@freumh.org> <acme account org for inclusion in the x509 distinguished name e.g. Freumh> <domain e.g. freumh.org>

This is at an ‘alpha’ quality. Work to be done includes using cert renewal with sturdy refs. Anil said to look at OCurrent OCaml CI for this.

§Federated Identify

Brainstormed with Jess about (first) what I’m working on/thinking about:

Then she explained her Identity Service to me, and I get it now. It’s inverting the flow of ‘identify’ form a pull-based model to a pull based model. And any piece of information (such as an age, email address, etc), can be tagged with a cryptographic reference (e.g. with macaroons).

I think we need to understand some matrix proposals to make an informed design of our federated identity service, specifically:

• P2P which hosts a homeserver on every device and communicated via a ‘pinecone’ overlay network which emphasises local connectivity a la haggle. Really cool!
• CryptoIDs MSC4080 provides a pre-requisite for account portability with per-room PseudoIDs that can be managed by clients.
• Portable Identities MSC2787 describes how to enable account portability. These two specs talk a lot about the crypto but I’m unsure how the user identity resolution to a homeserver address will work. There is some talk of DIDs. It seems ActivityPub people are thinking about similar things with ‘Nomadic Identities’.
• 3PIDs Matrix supports 3rd-party-ids (3PIDs) as a method to authenticate, identify and discover users. Jess’ Tardis design seems like a great alternative architecture to this, might necessitate protocol changes that our proxy idea we floated wouldn’t.

I skimmed Bluesky and the AT Protocol: Usable Decentralized Social Media by Martin Kleppmann et. all.

• It observers a difficulty with Mastodon/ActivityPub is that the server’s domain name becomes part of a user’s username which hinders mobility, and ‘only a small fraction of social media users have the technical skills and inclination to [host their own]’.
• (I think Eilean is one potential solution to this, but there is still the issue of discoverability across servers and the cost of self-hosting.)
• It proposes a decentralised architecture instead of a federated one, and ‘opening up the internals of a service’ for a ‘marketplace of ideas’.
• At this point in reading the introduction my question is, what technical mechanisms prevent centralisation of a service?
• Bluesky proposes a globally unique ‘handle’ per username which requires some centralised authority, instead of Mastodon’s per-server uniqueness.
• They discuss using a blockchain based naming systems but want to avoid requiring purchasing cryptocurrency.
• Ah, they use DNS to provide unique names!
• I think this is equivalent to proxying a personal domain to a hosted mastodon server – which I’ve said should be possible for both mastodon and matrix for a while (but afaik isn’t supported).
• (Can you proxy with a .well-known?)
• This makes DNSSEC all the more relevant.
• They have some concept of multi-homing (organisations can allow users to hang off an institutional domain).
• I really agree with their algorithmic feed discussion, and this is something I’ve though Mastodon should have since I started using it.
• They have a concept of Personal Data Servers (which remind me of specialised databoxes), and public indexing infrastructure analogous to search engines.
• 3.5 User Identity uses DID’s for account mobility, that are hung of a domain name (or HTTP .well-known) and point back to a domain name (bidirectionally).

§VURL

The idea is a DNS-inspired resolution to rrs better suited to larger data types e.g. git, file, etc. Expanding resolution to the whole URL. This could be stored in a store with the path a hash of the contents for uniqueness a la Nix. The resolver would keep bidirectional track of resolutions for provenance end replaying. Maybe this is the resolution/replay/caching mechanism behind shark; shark is a tree of URLs.

I should type up a brief doc describing this.

§Eilean

It looks like George Shammas from JS has make his NixOS config public, and the matrix bridges might be useful for Eilean.

Speaking of Eilean, with ACME cert provisioning and DNS record modification it could provide a 100% internet.nl scoring website & mailserver out of the box. I’m thinking about whether this could be a paper. Maybe as a use-case in the capability DNS paper.

§MirageOS Retreat

Patrick and I have signed up to the MirageOS restreat with ideas to work on hibernia, ocaml-dns authoritative server DNSSEC support, a MirageOS PiHole.

§Teaching

Supervised Robinson Part IB networking. It’s really great teaching a course you know a lot about and are passionate about. I’m trying to make it engaging by giving them some (optional) practical homeworks.

And then, completely optional practical ‘homeworks’ are:

• To traceroute analyse a path to a website, say, freumh.org. Bonus points if you can tell me what country it’s in.

• To try deploying a website, from scratch. What does from scratch mean I hear you say? Well, however far you want to take it.

  You could host it on a Virtual Private Server ¹ with a webserver like nginx/caddy. Make it accessible over IPv6 for bonus point.

  If you’re bold, could you use an old laptop/raspberry pi? What problems might you run into?

  You might want to get a domain name for your website. You could even host the nameserver yourself with e.g. bind9.

  You can provision TLS certs with an ACME CA ² like Let’s Encrypt for HTTPS.

  Try using https://internet.nl/ to test your new cyber-home. You might need to think about DNS security.

  Look at what traffic you get. Is there any? Is it malicious? Are the clients humans are bots? Where are they from? What clients are they using?