[saag] Re: Covert Web-to-App Tracking via Localhost

On Wed, Jun 04, 2025 at 07:42:47PM -0700, Watson Ladd wrote:
> > Client certs are very poorly supported in general.  What I'd like to see
> > [...]
> 
> Why is this worth doing?
> 
> We already have a solution to authenticating HTTP clients and doing
> authorization, and it's called SAML/Oauth2/Webauthn/etc. It's a mess, but
> it has the great advantage of being deployed and widely supported.

Mainly because the whole world isn't HTTP, sadly, so:

1) as you say SAML/Oauth2/Webauthn/etc. are a mess, and they're not
universally supported,

2) not all apps are HTTP apps (e.g., Postgresql, SQL Server, etc.),

3) and many of the non-HTTP apps that don't support SAML/Oauth2/
Webauthn/etc. do support client certs but very poorly (as I described).

Many of these apps that don't support SAML/Oauth2/Webauthn/etc. support
client certs, yes, and even Kerberos.  But Kerberos is kind of a pain to
deal with.  As a co-author and maintainer of Kerberos orchestration
software, where that is used Kerberos works great, except that getting
arbitrary "claims" or "authorization data" out of Kerberos tickets and
into the hands of apps is nigh impossible -- and I say that as a
co-author of RFC 6680, which was supposed to remediate that.

Now, PostgreSQL does have ongoing work to add Oauth2 support, which is
cool, and soon enough other apps will get that too.  But these apps
often have client cert support, and client certs would be pretty awesome
too[*], and it'd be nice if that support was actually usable (it isn't).

[*] With any authen. system where the supplicant possesses private/
    secret key material and they have to use a proof-of-possession
    protocol you end up wanting hardware token support and being sad
    that you can't get it or that it's too slow, so you end up having to
    orchestrate short-lived credentials that use software keys instead
    or in addition to possibly-longer-lived hardware ones.  But if you
    do that orchestration then these systems work quite well.  Kerberos
    for example.  At several $EMPLOYERS I've had Kerberos is still in
    use due to their having very convenient and fast credential
    orchestration systems.  There is nothing so different about PKIX
    that it couldn't work the same way, and unlike Kerberos getting
    things like SANs out of certificates is trivial enough (though not
    as trivial as in the case of JWTs).

> Fundamentally the architecture of the modern web app is hostile to anything
> below the HTTP layer working. This doomed channel binding cookies and much

I agree completely.

> else. There's too much between the client and the application to do
> anything else. If you want to extend HTTP, you need to make sure each
> intermediary adds value once it supports it, even if other parts of the
> chain don't. Things that require every step along the chain, or even just
> one particular step, to adopt something before they provide value
> (especially to other elements) have a massive problem with deployment.

Yes, I agree fully.  Channel binding was an attempt to bridge that gap,
but it was still too big a chasm.

> > If we're going to expand this thread to HTTP client authentication...
> > what I most want is an extension that allows clients to figure out how
> > to fetch the [Bearer, like JWT] rocks the servers want.
> 
> Oddly I do not have this problem when using the only application that
> matters, the browser.

You're probably using OIDC though, not JWT.  Or you're using JWTs w/o an
`aud` claim.  To my knowledge Chrome, FF, etc. do not know how to fetch
Bearer tokens.  They know only how to chase redirects (or do Negotiate,
i.e. Kerberos), and the redirect workflows are SAML and OIDC, not plain
JWT.

> I do have plenty of colleagues who bemoan the fact that the small fraction
> of the userbase they represent does not have a way to authenticate to email
> because of this. But it's completely understandable why this problem is low
> on the priority list, even if it means that fraction of people people have
> to deal with horrible UI issues rather than use the UI they would like.
> IETF is not great at pushing things without actual industry demand.

Yes, well, we could extend IMAP and SUBMIT to handle JWTs.  Has no one
done this work?  And then it needs to be implemented in the MUAs.

Nico
-- 

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]