Design a private key distribution infrastructure for TDNS

[johanix]

A number of TDNS features depend on being able to modify the zone data and therefore also be able to re-sign the zone data (for DNSSEC to work). The obvious drawback is that we then need the private keys at the edge.

It is also worth pointing out that all the commercial DNS services now provide support for key distribution to the edge, so while TLD zones are unlikely to use this (given external anycast providers), for other zones this is becoming the new normal.

Manual distribution of private keys from server to server is bound to end in tears. Automation is needed. So what is needed as a start is essentially:

• [ ] A new zone option that explicitly allow distribution of private keys for that zone among auth servers.
• [ ] One alternative: a REST-API between server with mTLS protection of the data.
• [ ] Another alternative: Secondaries publish a KEY record with key that the primary may use for encrypting the data. The primary encrypts the data and sends it via (yet another!) ENDS(0) option :-)
• [ ] Regardless of which the new KeyState option may be used to figure out the state of the keys at each secondary so that it is possible to know when things are out of sync or not.

[johanix]

After listening in on the JOSE WG during the IETF I learnt a bit about HPKE, which is a rather new framework that ought to fit this purpose quite nicely.

Once we get to this I think we should take a careful look at HPKE, and in particular the Cloudflare implementation on github.