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

[Mohit Sahni <[e-mail]>]

Hi Ryan,
Thanks for answering my question in a lot of detail. I asked this
question in the context of a private PKI for client certificates. You
can assume a scenario where the client certificates are issued to
users/devices in an organization from a self service portal by the
organization's existing private PKI for 1000s of users under different
domains (multiple CAs).

What I get from your answer is that using CT for client certificates
makes sense when:

1) There is an existing private PKI.
2) There are multiple CAs issuing the client certificates.
3) The PKI uses non Web PKI (non public) CT log servers and auditors.

I don't agree with your comment about following the same priority
preferences that exist for server certificates, the [2] and [3] makes
more sense when reversed or kept at an equal priority in the context
of client certificates. Here is my reasoning:
In the server PKI, it is practically easier to make changes in the web
servers to support [2]  (i.e. sending the SCT extension by pre
fetching the data from the CA) but it may not be that easier to
implement it on 100s of thousands of client devices. Imagine a large
cell phone manufacturer implementing [2] for all the devices that they
have sold in the last 10 years.

Thanks,
Mohit

Server certificate priority list:
[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


On Sun, May 9, 2021 at 3:20 PM Ryan Sleevi <[e-mail]> wrote:
>
>
>
> 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.