I asked for time to discuss this in Madrid, many thanks, it has actually been very helpful. My concern was that DNS Handles are clearly an important emerging technology, the logic of using DNS names to identify people ends up with using the DNS to publish public keys for user authentication and TLSA is clearly at the intersection of DNS and public key client auth.
Having gone through the thought processes and discussed with various folk, I now think that DNS handles are an entirely different use of the DNS and while we might end up using TLSA records, that needs to be an entirely separate use from DANE/DANCE. The reason for this is rather interesting, at least to me. OK, so the detailed rationale. In the originally intended field of use, DNS is an infrastructure that transforms a label 'example.com' to an IP address. While the IP address is cacheable, it is ephemeral, the lifetime is short, at most a few days. When the DNS is used to retrieve a certificate, the certificate is bound to the DNS label which is also ephemeral, albeit with a lifetime of years and the certificate thus has a fixed expiry. DNS Handles are a completely different use of the DNS. The ephemeral DNS name is mapped to a public key that is a permanent signifier with the semantic 'the set of people who know the corresponding public key'. That set can change over time of course, the key can be disclosed making the set the universal set, it can be lost making it the empty set, the characteristics of the members of the set can change. But those are separate questions that have to be addressed in a system but they are addressed by reference to the public key signifier, not the DNS name. The practical upshot of all this is that a DNS Handle is merely a syntactic sugar for a public key, it is a token that is redeemed for the thing you really want. This is the core of what makes using DNS Handles as retrieval indexes for JSContacts stuffed with application public keys so powerful, if Alice tells Bob 'you can get my contact info from @alice.example.com', that is a one shot deal. Bob uses the DNS label to pick up the contact package after which the contact is updated using the descriptive information in the package itself. The DNS handle is a one shot, same as a scanning a QR Code is. The particular application area I am interested in for applying TLS client auth is to enable the use of DNS handles as a means of managing authorizations. So Alice buys an Internet connected thermostat for her HVAC, she connects it to her personal collection of devices by scanning a QR code to pull a JSDevice specification listing all the ways that here configulator app can onboard it (Brewski, MathMesh, etc.). At this point, she needs to specify the set of people who can change the temperature and for that, she lists the DNS handles: @alice.example.com @bob.example.net @carol.carolsdomain.me Now here is the important bit, the handle isn't converted to a public key when the user attempts to access the device, conversion takes place when the handle is authorized to use the device. So the authorization list actually looks more like @alice.example.com KBOT-QD4R-US35-AIN6-O7YA-PL7P-TKGQ @bob.example.net KB2C-UKBU-7WCU-DD7G-UPTR-CIPP-H53F @carol.carolsdomain.me MB4Y-FNEF-EOBU-4GQ3-UAJH-YAUY-533O This is essential because Alice is granting authorization to the Bob she knows, not whoever happens to hold @bob.example.com in the future. Alice cannot be expected to spend her time curating her access control lists to determine who has changed their handle. One side effect of this is that the devices can all be used when the network connectivity is lost for periods of weeks without the need for additional local network infrastructure. It won't be possible to add users through the normal channels when the network is offline but that isn't a 90/10 problem, it isn't even a 99/1 problem. It is a corner case best left to hardcore off gridders because we are building an inter-network here, not an airgapped LAN. [Of course, in a more typical deployment, the authorization is being managed at a higher level than the individual device. Alice has some application or infrastructure that allows her to create access lists and apply them to groups of devices. The devices can have features reserved for only some people, etc. etc.] So how does this affect our use of TLS Client auth for @nything devices? The DNS Handle infrastructure I am building is predicated on the emergence of 'Handle Service Providers' that will be providing a suite of services to their users/customers. The reason I am pushing hard on this now is that if people are setting up paid HSPs, I want them to all sign up for the full suite. My expectation here is that if the approach were to take off, it will be a natural part of the VPN/anti-malware service packages that are offered. If we all started using DNS handles, operating a HSP would more than double the value of a VPN offering to many of their customers at negligible cost. So what I want the HSP to do is to operate a private label CA for the user, with a personal private root and individual device certs issued to the devices authorized by the user. These won't be bound to a DNS name, or at least not an ICANN routable one. It is probably best to present the users personal id as a DNS label with at least two levels in a subjectAltName but that name is likely to just be a digest of the private root key: KBOT-QD4R-US35-AIN6-O7YA-PL7P-TKGQ.any.arpa (root) hvac.KBOT-QD4R-US35-AIN6-O7YA-PL7P-TKGQ.any.arpa (device) These are not names that users ever need to see (unless they are doing their own HSP), that is why we have the handles. Let us assume that any.arpa is registered for this purpose. Relying devices can then be told that when they are presented with a client device claiming a name in *.any.arpa, they validate the end entity cert by checking it chains to a root whose public key matches the digest. The certs can specify distribution points for CRLs and OCSP if desired. The HSP then binds the user's private root to their handle using either a TLSA record with some new certificate type or as a prefixed TXT record as we do for other handle bindings. Again, I don't care because any HSP that can run a PKIX CA can populate 'new' DNS records. The upshot of all this is that implementing the authentication part of client auth is merely checking that the cert presented chains to the root identified when the user was granted the authorization. The approach allows a device to perform authentication and authorization in either order or in parallel. Devices can also support client certs issued via traditional approaches but that will of course require more path math support. All in all, I think this approach falls out very nicely. While we are changing the model of how we use DNS, it is a change that is entirely logical and falls out of the constraint that Alice isn't authorizing the holder of a DNS name or an account somewhere, she is authorizing the individual who holds the DNS name at the instant the authorization is registered and nobody else.
_______________________________________________ dane mailing list -- [email protected] To unsubscribe send an email to [email protected]
