One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Kerberos realms also closely resemble DNS names and discovery can be tied into SRV records and well-known-names.
Kerberos tries really hard to do authentication and rely on other, existing systems for the other bits. If your resolver supports DNNSEC then it'll check your Kerberos-related DNS records as well.
On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation. Corporations and other entities typically use Active Directory on local domain that's not otherwise used on The Internet. SSH keys are trusted on a per-key basis, so I don't see a great need for it to be tied into the Web/SSL CA systems because trust is established in other ways and it's almost always with an entity that you already know or have a relationship with.
Of course, there's a case for delegation, etc within an organisation, but that's a different problem to delegation in global DNS.
I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
Cross-realm trust setup.
> One of the problems with WebPKI is that it's just for the web! Things like SSH and eMail can still benefit from a common, managed authorization infrastructure.
Well, no, you could use the WebPKI for SSH, it's just that you wouldn't want to: it's too dangerous. The WebPKI isn't really a PKI as PKIs were intended to be.
What I would say is that we really need to fix the WebPKI problem.
> Kerberos is largely transport agnostic: it has been integrated into many protocols such as telnet, ssh, ftp, http, anything that can use SASL or GSSAPI, even stuff like Hadoop.
Quite true. This is a key strength of Kerberos.
The trend I'm observing in corporate networks though is towards HTTP for everything, and there, Kerberos just doesn't fit in the way it does in GSS applications. In HTTP the way to use Kerberos is as a bearer token system.
> On the other hand, I don't see any clear evidence that users want a global hierarchy in their authorisation.
Well, not so much in corporate networks, and certainly I don't need hierarchical authorization on the web so much, though in fact many sites like to use each other for authentication and authorization. E.g., CIs let you authenticate with GitHub/GitLab/... credentials via HTTP redirect-based mechanisms.
This isn't so much about hierarchy as about federation. But that federation is predicated on WebPKI, which isn't-but-should-be-damnit hierarchical.
> I also see a small need for some kind of probabilistic uniqueness to avoid namespace issues with mergers and acquisitions. Most existing solutions that have a namespace at all (AD, Kerberos) handle this reasonably well already without guaranteeing global uniqueness.
Oh boy, tell me about it. I've been involved in half a dozen mergers and acquisitions... Even today, too many systems do "realm-chopping", which re-creates the collision problems that you solve by adopting Kerberos or alike.
> So what part of Kerberos is at its scaling limit and how could it better mirror the DNS without adding too much complexity or taking on too many more responsibilities other than auth?
Back to scaling, the problem is that cross-realm trust setup is utterly manual and unsafe. In order to scale to the Web using DNS hierarchy it needs to be made automatic, probably using DNSSEC/DANE, or a proper PKI run by the DNS registries and registrars (besides DNSSEC, which is a PKI, of course).
Of course, if we had a proper PKI, we wouldn't really need Kerberos anyways. The two things, PKI and Needham-Schröder protocols like Kerberos, are duals. But there is a slight semantics different between the two that strongly favors PKI: in PKI any CA can impersonate any entity within its namespace, but one CA cannot MITM protocols like TLS when crossing namespaces (and when using certificates for both, the client and the server), whereas in Kerberos, any KDC in the trust path from client to server can not only impersonate clients in its purview to the server, but also MITM any clients to any servers when that KDC is in the trust path.
Also, constructing a global DNS-based proper Kerberos infrastructure is comparable in difficulty to constructing a global proper PKI. (EDIT: And since we really need a PKI... and the two are duals...)
Lastly, Kerberos has more online infrastructure requirements than PKI, though PKI really needs to be used with short-lived or otherwise fresh certificates in order to avoid the need for online revocation infrastructure. This difference also strongly favors PKI (EDIT: I wrote this favors Kerberos, but I'd meant PKI).
BTW, here's a very simple protocol based on DNSSEC/DANE that looks a lot like TLS 1.3 with the zero rtt option: lookup the server's long-term public ECDH key in DNS (with DNSSEC/DANE), send {client_ephemeral_public_ECDH_key, SNI, E(shared_ECDH_key, client_certificate, validation_chain, signature)} to the server, and expect back {server_ephemeral_public_ECDH_key, MAC(shared_secret, client's message)}. The shared secret in the first message would be based on the client ephemeral and the server's long-term key, while the shared secret in the second would be based on both ephemeral keys and the server's long-term key as well. The client certificate could be signed by a DANE-authenticated CA, and the validation chain could be just the DNSSEC chain. The client certificate could be a key agreement certificate, in which case the signature would be more like a MAC using an agreed key. This might seem familiar to you... it's exactly the same as the good old AUTH_DH/mech_dh from Sun, but with DNSSEC as its publickey database. This scheme has a lot of properties like Kerberos, such as supporting .5 and 1.0 round-trip handshakes!
Even to the extent that there are exceptions to the rules they make, they made those exceptions too.
For example, the sovereign entities agreed centuries ago that none of them owns the open oceans but vessels that sail on those oceans shall display the flag of a sovereign entity and the entity thus flagged shall be responsible for that vessel's conduct and operation. This flag state regime proves to be problematic in certain ways in practice.
So what happened? Did some alternate power arise to challenge the sovereign entities in this regard? Nope. The European countries, annoyed by "flags of convenience" on the vessels they saw just arbitrarily instituted a new policy, under the Paris Memorandum Of Understanding. No need to "challenge" any existing rules, as sovereign entities they were entitled to just make up new ones. Vessels entering a European port needed to obey the Paris MOU rules, sometimes getting inspected and if necessary prevented from leaving until they rectified any problems to the port's satisfaction. Was that legal? It was now because sovereign entities had agreed that it was so. The new model was a big success and similar Port State Inspection rules soon followed elsewhere.
No PKI, whether loose like WebPKI, rooted like DNSSEC (or as PKI was intended to be), or with multiple roots sharing subtrees (e.g., as DNSSEC would be if, say, Russia decided to require Russians to use Russian roots that happen to sign com and such as they are), can possibly get around the fact that the certification authorities that make it up are subject to the jurisdiction of some government. It's why we all don't want the CN NIC in our trust anchor sets, for example, or only want it if name-constrained.
There is not getting around this. So u/tptacek doesn't trust the DNS root, but so what, why should he trust any WebPKI CA at all, or all of them? Any one of them can be compromised by the end of a gun, and then all who have it in the trust anchors will be compromised too.
Sure, there's CT (certificate transparency), but there is nothing so PKIX-specific to CT that it couldn't be applied to DNSSEC, and anyways, I'm unconvinced that it's enough. There comes a point where certain governments don't even care if they leave evidence of their nasty behavior for all to see -- when push comes to shove, any government with jurisdiction over you can end your happiness and even your life. Oh? The world can see? But what can the world do for, e.g., HK? A big fat not much.
Imagine you're a subject of interest to the U.S. government, and they're willing to risk public knowledge of their access to root keys, say, in order to spy on you. And say you're vising some site like antifa.github.io. So you ask . for io, and io for github.io, and github.io for antifa.github.io, and only at the last hop can the LEO/TLA system spying on you decide that yes, they want to MITM you there. So either they have to MITM you everywhere, or they have to MITM you only at zones they can control, and this is a decision they have to make online. That's a big deal. If they decide to MITM you when you asked for io, but you expected this so you had io's public keys, and . tells you different keys, then you've detected the espionage attempt. WebPKI can't do this. By the time some server (or MITM) sees your SNI they've also seen your DNS queries. Even if you're using DoH/DoE (which also gets you similar protection in a DNSSEC world), if the SNI is not encrypted, still, they know what to do. And so on. Let's say you're using DoH/DoE with a resolver the LEO/TLA can't control, then they could simply kick your door in and take your stuff and beat you up. Crypto can make things harder for them, but not infinitely harder. The CCP won't give a damn about leaving evidence in CT logs, for example -- maybe today they do, but when push comes to shove, forget about it.