Restarting the thread clean
1) Yes, I agree that the DNS model is OK for our purposes. Recognizing that there is little we could do to change it means that we should just accept the model as it is
1a) That does not mean we have to accept the DNS protocol. that is much more malleable (see DoH)
2) We should decide on a division between service discovery and service description and move everything that is not essential to discovery to description.
2a) I still want to put key digests and even keys in the DNS however because that is the only way that we can encrypt the host key exchange.
2b) Latency is really critical in applications but not necessarily for discovery. The cost of a round trip is not very important if I can cache the resulting key exchange on the client side for a year or more.
3) UDP is not a panacea for DDoS but it does allow the service to perform its own DDoS mitigation without consuming system resources (TCP/IP does not).
3a) Assume that there is regulation at some point that requires residential gateways to perform egress filtering requiring the source address of all packets sourced to be valid. I had discussions earlier this week with senior people in various governments where I made that recommendation. I think we can get it at some point.
3b) Before a service does any 'expensive' action, assume we make use of one round trip to perform a challenge/response
3c) We can use a client-Host key exchange to encrypt the client-Service key exchange protecting both the domain and service.
So the way I see this sort of thing working is this:
First, forget the conversations between the resolver and the authoritative. Assume that these are performed by a caching resolution service that aggressively pre-fetches records just before they expire from the cache. So 99% of the time or more, 1.1.1.1, 8.8.8.8 or whatever will have the information any client asks for in cache. So the resolver/authoritative latency is irrelevant. and indeed we can expect that at some point, there will be a DNS protocol optimization to make this more efficient by pushing updates out to subscribers in some sparse updates-only fashion.
Second, assume that hosts and services are different things with different keys. The host keys are supplied by DNS discovery, the service keys are provided by the host.
Third, assume that the endpoint here is a fully UDP based Web Service protocol. The lower layer may be QUIC or something much simpler that only supports short requests and responses.
_mmm._tcp.example.com SRV 1 1 6666 host1.example.com
_mmm._tcp.example.com TXT "v=mmm tls=KCM5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN"
host1.example.com A 10.0.0.1
_key.host1.example.com TXT "v=key hek="PAQH-PKX2-BAIJ-I7EC-XGAL-7GWT-DDFP-MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4"
Client query is
_mmm._tcp.example.com DISCO
Back is returned the following responses:
Packet 1: SRV, Authority chain, DNSSEC signatures
Packet 2: A, TXT records
The client then performs a HEK request of the Host on port 6666 using the Curve25519 key PAQH-PKX2-...
If the service is under load, it may well require the request to be resubmitted with a DDoS cookie. But in ordinary circumstances, this is unnecessary. After one round trip, the client has a WF128 master secret that can be used to encrypt a Hello inquiry on the service to get the implementation details and to perform a Curve448 key exchange for production use.
For the Mesh Services, I expect that the discovery services would in any case be simply handing the user off to a different host after the initial connection as there is really no reason to have all the accounts on the same host or to funnel all the requests through a first tier simply to redirect to a second. Yes there are good security reasons for two tiered models but that does not mean that every first tier service needs to be able to support any user at all.
