Re: [TLS] [EXTERNAL] [lamps] Distinguished names for self certified TLS client authj

[Phillip Hallam-Baker <[e-mail]>]

Hmm... looks like this is a piece of brokenness in the browsers.

I see this as a two step thing. First there is 'getting it to work in the
legacy browsers' and then there is 'doing it the right way'.


For the second step, I have actually written my own browser (yes really)
and one of the goals of that work is precisely so that I can control the
privacy etc. profiles and show how I think it can be done right.

The idea of the client cert selection extension was to avoid the need for
that cert selector extension. But as the article points out... privacy
hole! Ooops. What does Firefox do if a server specifies a list of client
cert DNs that only matches a single cert? The goal was to avoid the need
for the selection box. But we definitely need that 'do you want to send a
cert' dialog.


My plan for Phill's Hypothetical Browser is to allow users to specify site
profiles and apply their own security policies to them.

So Alice has 3 machines A, B and C. She wants to have a seamless experience
across all of these. So log into the NYT on A and she will automatically
log in on B.

Alice uses a number of different sites

X, Y, Z are sites she uses for work and it is important TO ALICE that the
site X knows that she is the same Alice who is doing something on site Y.
P, Q, R are random Websites that Alice uses but she certainly does not want
P to know that she also uses site Q.

So my plan here is that Alice can declare security policies 'Work' and
'Pseudonymous' so that context is shared between X, Y, Z but P and Q and R
are each isolated with entirely separate cache and cookie settings.

For investigation work, I would also want to be able to specify that a site
be accessed through a forensic proxy, for personal privacy I might bounce
requests to different sites off different proxies.

So for my extreme privacy browser, I can specify that a site should use a
shared certificate as specified by the security label applied to that site
or a site specific certificate to prevent linkage.

The github is here:
https://github.com/hallambaker/PhillsHypotheticalBrowser


My thanks to the Microsoft WebView2 team for making this possible.


On Tue, Jun 14, 2022 at 4:44 PM Mike Ounsworth <[e-mail]>
wrote:

> Hi Phillip,
>
> What clients are you trying to use this with? Browsers? This almost feels
> like a user-agent question: "What CA DN do you want the server to prompt
> for so that you put up the right certs in the popup?". Is there a CA DN
> that you can specify that will cause FF / Chrome to show the user all their
> loaded certs?
>
> Note: back in 2018 I was fiddling around with this for a stackexchange
> question and found that (by default) Firefox politely waits for you to
> select a client cert from the popup, whereas Chrome just starts spamming
> client certs at the server until it accepts one. I feel like user-agent
> behaviour is going to affect the viability of your idea here.
>
> https://security.stackexchange.com/a/199518/61443
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
> From: Spasm <[e-mail]> On Behalf Of Phillip Hallam-Baker
> Sent: June 14, 2022 2:58 PM
> To: SPASM <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS
> client authj
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ________________________________________
> [Yes, I am aware of the FIDO work and it is a completely different use
> case, does not apply to non web applications. TLS Client Auth is an IETF
> spec and thus within IETF scope.]
>
> I have an infrastructure that makes private key management really simple
> for end users. They can manage private keys across devices without being
> aware they are doing it. This technology has obvious applications for
> existing public key authentication schemes including EAP, FIDO and TLS
> Client Auth.
>
> When looking at TLS client auth it seems to me that it is much closer to
> being a viable replacement for some uses of passwords than experience leads
> us to believe. In particular, I have maybe 5 accounts I might use a
> hardware token to secure but I have several hundred Web accounts that all
> use the same password because when it's not my asset and I am not being
> paid, I don't use my brain power to remember the password.
>
> So my basic idea here is that Alice connects all her devices to her
> personal Mesh and they are automatically provisioned with a device specific
> cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn
> being (optionally) credentialed under Alice's personal Mesh via an
> extension if the goal is to establish that the 'Alice' visiting site A is
> the same as the Alice visiting site B. For cases where we want to prevent
> linkage, we develop a separate CA per site.
>
> This is not how PKIX is intended to work of course. But the deployed
> infrastructure supports PKIX and so that is the framework we have to work
> within.
>
>
> Looking at how TLS Client Auth works as deployed, a server sends a message
> back to a client saying 'client certificate required' and a list of
> distinguished names of CAs it will accept.
>
> So what I want to know is not 'should I do this', but 'what is the string
> I should send when I do'. That is, this is something I am planning to do
> and so I am asking what approach is least likely to have unintended effects.
>
> I see a need for two distinguished names:
>
> A) 'Self signed CA speaking to any relying party'
> B) 'Self signed CA speaking to a specific relying party'
>
> The server is going to check the certificate chain itself on the other end
> of course.
>
>
> And again, yes, I do fully understand the limitations of transport layer
> client auth. That is why I make use of my own authentication layer for Web
> Service transactions.
>
> Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.
>