Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake

[Ryan Sleevi <[e-mail]>]

On Sun, May 9, 2021 at 1:14 PM Mohit Sahni <[e-mail]> wrote:

> Hello TLS WG,
>
> RFC6962 only talks about support of CT to verify the server
> certificates, however while working on zero trust services that
> require MTLS for each connection, I realized that enabling CT for
> client certificates can make the TLS handshakes with Mutual TLS more
> secure. (I don't want to go into details of how CT can make it more
> secure as those benefits are already mentioned in RFC6962).
>

Question: Are you assuming existing Certificate Transparency logs (i.e. for
Web PKI), or are you standing up custom logs?

I'm not aware of any client implementations that allow custom logs, so I
think it's reasonable to take implicit that you're discussing Web PKI, in
which case, using MTLS like this unquestionably is *less* secure and
actively harmful to security, due to the significant fragility in mTLS
(e.g. a lack of automation on the client side, a lack of robust
verification on a server side). This is why, for example, there have been
discussions about forbidding serverAuth certificates from the Web PKI being
used for clientAuth, due to the associated harms.

Assuming you are discussing a private PKI, then I would say the
justifications of 6962 are things you can address early on with the PKI
design (i.e. avoiding the multi-party PKI that the Web PKI has). So it
should not be taken for granted that CT is the "right" solution.

However, going further, and if we assume a private PKI, with a
multi-stakeholder scenario that makes 6962 useful for your case (i.e.
implying the PKI design is already problematic), then there's not a way for
the server to indicate its expectations of the client's certificate being
logged, and this is arguably a feature, not a bug, since "being logged" is
a nonsensical phrase without understanding the server's set of logs.
Indeed, the "right" way to do this is to follow the same priority
preferences that exist for server certificates, namely:

1) Ideally, embedded within the (client) certificate itself
2) If not embedded, then included as part of the TLS handshake (which TLS
1.3 makes it possible for clients to send such information, and surely no
one would be building new mTLS on TLS 1.2 given the issues with client
certs in 1.2)
3) Optionally, embedded in the OCSP response, although virtually no client
mTLS implementation supports OCSP stapling correctly, which is also a TLS
1.3 thing

However, again, going back to first principles: If your goal is to
repurpose existing PKIs, such as Web PKI, for client certificates, then
that's fundamentally flawed on many levels, and has the risk of creating
both operational issues for you and your clients, and in doing so, creating
security issues for the broader ecosystem of users relying on the Web PKI
for servers. If your goal is to establish a new PKI for such purposes, then
there are plenty of approaches early on in the design that can avoid the
set of considerations that directly lead to CT, and while there's still an
indirect benefit, it may be that you find the simplicity of a secure,
private PKI avoids the need entirely.