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
