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 <ryan-ietf...@sleevi.com> wrote: > > > > On Sun, May 9, 2021 at 1:14 PM Mohit Sahni <mohit06...@gmail.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
