Subject: [TLS] Fixing TLS Client Authentication UI

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Dec 2021 12:28:01 -0500

As many of you probably know, we recently lost Kim Cameron, a giant in the
identity and access space.

This caused me to rethink the reasons for the failure of Identicard, one of
his most promising proposals. Identicard made using public key
authentication easy, just pick the persona you want to authenticate under
and click on the corresponding card.

The main reason I think Identicard failed is that it didn't have an answer
for the credential portability problem. Even in the mid '00s, using
multiple devices was common. If I can't get to it from my phone AND my
desktop AND my laptop AND my tablet, then it isn't going to work for me.
But username/password does.

So I have built a system that addresses the problem of key portability.
Seems like we should maybe revisit TLS Client Auth and see if we can make
that work in a 'Zero Effort' configuration.

What I mean by that is even less effort than Infocards requires. TLS server
auth requires no user input. The only user input required for client auth
should be asking the user if they want to authenticate to the site. And
that should be like 'accept cookies', one time and done (only giving the
user more control on revoking that decision).

Thanks to the Microsoft WebView2 team, I have my own experimental browser
running so I can testbed an implementation here. What I need a bit of help
on is understanding the API affordances of the legacy browser/server
infrastructure because that is going to constrain what is practical.

In theory, TLS client auth could use a non PKIX credential, in practice,
that option closed decades ago. The client is going to have to present
credentials to the service that are at least syntactically consistent with
PKIX even if the credential itself is simply a wrapper around a SAML or
JSON credential.

TLS Client Authentication is inevitably going to require services to
perform authorization. So we can treat parts of the PKIX spec with contempt
bordering on grievous bodily harm.

For example, to validate to a DNS issued credential [email-masked]

1) example.com creates a PKIX certificate signing key kp, hash hkp
2) example.com publishes an authorization statement for hkp in a DNS record
in zone _hkp.example.com
3) example.com creates a cert signing cert for kp using the private key for
'DNS Trust' published in the specification

At this point, example.com has successfully diverted the PKIX trust chain
into a DNS trust chain.

But even this is rather more than we need for most web applications. For
those the questions are

* Is this the same user who visited before?
* Is this the same user who visited before from that particular device?
* Is this the same user who visited from that device in the past 24 hours?

For these the Web server can simply bind direct trust to a key. If we need
binding to a persistent identity we can do this out of band on a completely
different device. The service tells the browser which form of binding it
will accept by specifying the pro-forma root certs.

For example, Alice wants to check her portfolio from a mafia run coffee
shop. The browser creates a new client cert chain for the session, splashes
a connection code XYZPDQ on the screen. Alice gets a ping on her watch
saying 'allow access by XYZPDQ'.

Good enough for read only access but would really hope that any trading
requires individual 2FA confirmation.

So all in all, I think we can provide a really solid, really transparent
user experience without any new protocol work. It will take changes to the
browser to make this really work for the end user but a change to one part
of the platform is plausible, changes to server and browser together
require decades.

I would expect initial interest would be limited to enterprise use where
they can say 'you will use this browser to do your job'. What I have
running is a C# wrapper around a captive copy of Microsoft Edge Canary so
it is a (very) full feature browser and all the maintenance cost is
offloaded. (Thanks to the Microsoft team).