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

<snip>
>
> > Except that maybe we shouldn't accept statements like "TLS 1.3 in widely
> > deployed", yet it's only really browsers, and they (browsers) don't
seem to
> > support useful TLS features like mutual authentication with 1.3.
>
> Client certs are very poorly supported in general.  What I'd like to see
> is that libraries apply name constraints to SANs, expressive local
> policy, as well as any local mappings of of the client cert's identity,
> and also for them to also provide the application with the raw client
> certificate _and_ the trust anchor to which it was validated.  In
> practice nothing of the sort exists, and almost all applications that
> purport to support client certificates can only be constrained by the
> use of trust anchors and they only provide the CN attribute of the
> certificate's distinguished name (which is totally useless -- SANs are
> far more useful).

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.

Fundamentally the architecture of the modern web app is hostile to anything
below the HTTP layer working. This doomed channel binding cookies and much
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.

>
> > The HTTP client authentication gap is a problem that seems to be
> > nobody's problem.
>
> Ain't that the truth.  Though what the relation to this thread is I
> don't know.
>
> 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.

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.

Sincerely,
Watson

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



--
Astra mortemque praestare gradatim

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