[TLS] Certificate Transparency for Client certificate in MTLS handshake
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). Here is how I think it can be supported and I am looking for your feedback on this. Approach 1: If a client has sent the signed_certificate_timestamp [RFC6962] in the client hello with empty data and if the server is configured to only accept the client certificates with a CT log, server will send the signed_certificate_timestamp extension with empty extension_data in the Certificate Request [RFC 8446 section 4.3.2] message to indicate that it requires certificate's Signature Timestamp as a proof that the certificate is logged with a CT server. On the client side, If it's certificate does not have an SCT extension, then the client can either be configured with a static SCT data or it can be configured to fetch it from an external server. The client can use the SCT data to add a signed_certificate_timestamp extension in the CertificateEntry in the Certificate message [RFC8446 Section 4.4.2 along with its certificate. Approach 2: Another way could be the CA of the client's certificate can send the signed_certificate_timestamp extension in the OCSP response to the server indicating that client has a CT log along with the log. Server can enforce both CT and Revocation checks at the same time. Please let me know your opinion on this and do you think there is some merit to standardize this. Thanks for paying attention to my email. Regards, Mohit Sahni ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
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 wrote: > > > > On Sun, May 9, 2021 at 1:14 PM Mohit Sahni 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 >
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
Hi Melinda and Rich, Thank for your comments, I agree that there is not much demand from the enterprise PKI but with the rise of IOT devices and automatic enrollment for client certificates, a need for some auditing of all the issued client certificates is becoming more important. Managing large services that use client certificates, I feel having some assurance that the clients have SCT logs and are not revoked will give me a better sleep at night. -Mohit On Mon, May 10, 2021 at 6:04 AM Salz, Rich wrote: > > > But I have to say, the core problem this proposal > faces would seem to be lack of demand on the part of folks who > consume client certificates. > > Agreed. In our experience, client certs are deployed from an enterprise PKI, > and the receiving consumers assume valid issuance. I'm not aware of any of > our customers (the few that use client certs) who also use a public CA, or > even more than one. > > Added the trans list. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi wrote: > > > > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni wrote: >> >> 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. > > > Right, I can understand the temptation to consider OCSP Stapling as a more > attractive solution, because it relies on the CA taking the requisite action, > and thus avoids the need for client implementation, in theory. But the > problem is that it's largely "in theory" - that is, robust OCSP stapling is > just as hard for clients to implement as obtaining SCTs directly. > > Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling looks > like, from the server side, which captures some of the challenges here. Few > servers robustly support this (I believe Microsoft IIS and the Caddy web > server are the two notable exceptions), and so the idea of pushing that all > to clients is roughly the same challenge as having clients obtain SCTs > directly. The main argument for OCSP-embedding over TLS-embedding is not one > of simplicity, but of centralized control and communication: the idea being > that you can have all your clients contact a single point of contact (the > CA's OCSP responder) to obtain the policy. > > For servers, in the context of the Web PKI, it's quite appealing to swap > priority for OCSP-embedding over TLS-embedding because of this. It equally > gives Web PKI CT Logs a single point of contact for purposes like rate > limiting and abuse detection, which can make it easier to address any > concerns. However, in the threat model of "Unreliable CA", where CAs continue > to fail to implement CT correctly [2][3], that seems to be missing the > operational lessons. Given the assumption that the model here was private PKI > with private CT logs, then you're likely better off with a (privately > expressed) policy mechanism on the client versus trying to robustly support > OCSP stapling on clients, since the failure mode here impacts not only CT, > but the revocation processing. > > [1] https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 > [2] https://sslmate.com/blog/post/apples_new_ct_policy > [3] > https://www.hardenize.com/blog/certificate-transparency-policies-diverge-with-apples-update I think you misunderstood me, I am not recommending the use of OCSP stapling here. I agree with you that the OCSP Stapling is practically almost the same as a client fetching the SCT and sending it to the server in the TLS stream. I am recommending that the CA/OCSP responder can attach SCTs as an OCSP extension along with the revocation status of the client certificate in the response to the server's OCSP Request and server can verify the certificate based both revocation status and the number of SCTs in the OCSP response from the CA/OCSP Responder. I know there are issues with how OCSP is implemented by various vendors but we can always work on learning from the mistakes and improve OCSP to make it more interoperable. Thanks Mohit ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi wrote: > > > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni wrote: >> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi wrote: >> > >> > >> > >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni wrote: >> >> >> >> 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. >> > >> > >> > Right, I can understand the temptation to consider OCSP Stapling as a more >> > attractive solution, because it relies on the CA taking the requisite >> > action, and thus avoids the need for client implementation, in theory. But >> > the problem is that it's largely "in theory" - that is, robust OCSP >> > stapling is just as hard for clients to implement as obtaining SCTs >> > directly. >> > >> > Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling >> > looks like, from the server side, which captures some of the challenges >> > here. Few servers robustly support this (I believe Microsoft IIS and the >> > Caddy web server are the two notable exceptions), and so the idea of >> > pushing that all to clients is roughly the same challenge as having >> > clients obtain SCTs directly. The main argument for OCSP-embedding over >> > TLS-embedding is not one of simplicity, but of centralized control and >> > communication: the idea being that you can have all your clients contact a >> > single point of contact (the CA's OCSP responder) to obtain the policy. >> > >> > For servers, in the context of the Web PKI, it's quite appealing to swap >> > priority for OCSP-embedding over TLS-embedding because of this. It equally >> > gives Web PKI CT Logs a single point of contact for purposes like rate >> > limiting and abuse detection, which can make it easier to address any >> > concerns. However, in the threat model of "Unreliable CA", where CAs >> > continue to fail to implement CT correctly [2][3], that seems to be >> > missing the operational lessons. Given the assumption that the model here >> > was private PKI with private CT logs, then you're likely better off with a >> > (privately expressed) policy mechanism on the client versus trying to >> > robustly support OCSP stapling on clients, since the failure mode here >> > impacts not only CT, but the revocation processing. >> > >> > [1] https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 >> > [2] https://sslmate.com/blog/post/apples_new_ct_policy >> > [3] >> > https://www.hardenize.com/blog/certificate-transparency-policies-diverge-with-apples-update >> >> I think you misunderstood me, I am not recommending the use of OCSP >> stapling here. I agree with you that the OCSP Stapling is practically >> almost the same as a client fetching the SCT and sending it to the >> server in the TLS stream. I am recommending that the CA/OCSP responder >> can attach SCTs as an OCSP extension along with the revocation status >> of the client certifi
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
Hi All, Thanks for providing feedback regarding checking CT for Client certificate in MTLS connections, it looks like that we agree to come up with specs for this. Further, it should be doable using the existing TLS 1.3 protocol without any changes as David and Ryan commented. I will write up an Internet-draft and get back to the group soon. Please feel free to share any other use cases you might have for validating CT for client certificates in MTLS connections. Regards, Mohit On Mon, May 10, 2021 at 6:55 PM Mohit Sahni wrote: > > On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi wrote: > > > > > > > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni wrote: > >> > >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi > >> wrote: > >> > > >> > > >> > > >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni wrote: > >> >> > >> >> 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. > >> > > >> > > >> > Right, I can understand the temptation to consider OCSP Stapling as a > >> > more attractive solution, because it relies on the CA taking the > >> > requisite action, and thus avoids the need for client implementation, in > >> > theory. But the problem is that it's largely "in theory" - that is, > >> > robust OCSP stapling is just as hard for clients to implement as > >> > obtaining SCTs directly. > >> > > >> > Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling > >> > looks like, from the server side, which captures some of the challenges > >> > here. Few servers robustly support this (I believe Microsoft IIS and the > >> > Caddy web server are the two notable exceptions), and so the idea of > >> > pushing that all to clients is roughly the same challenge as having > >> > clients obtain SCTs directly. The main argument for OCSP-embedding over > >> > TLS-embedding is not one of simplicity, but of centralized control and > >> > communication: the idea being that you can have all your clients contact > >> > a single point of contact (the CA's OCSP responder) to obtain the policy. > >> > > >> > For servers, in the context of the Web PKI, it's quite appealing to swap > >> > priority for OCSP-embedding over TLS-embedding because of this. It > >> > equally gives Web PKI CT Logs a single point of contact for purposes > >> > like rate limiting and abuse detection, which can make it easier to > >> > address any concerns. However, in the threat model of "Unreliable CA", > >> > where CAs continue to fail to implement CT correctly [2][3], that seems > >> > to be missing the operational lessons. Given the assumption that the > >> > model here was private PKI with private CT logs, then you're likely > >> > better off with a (privately expressed) policy mechanism on the cli
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
Hi Ash, Thanks for your input, we want to define the CT workflow for the client certs in the context of a private PKI using a private CT log server for auditing purposes. Web PKI CT log servers anyways cannot be scaled to accept CT logs for any random private PKI CAs. I will add your concerns to the security considerations section in the draft. I will also look into your draft related to DANISH BoF. The idea is that private PKI monitors can look for any improperly issued certificates in the logs and mark them as revoked. So if a certificate has SCT that means it will be audited and we can rely on the revocation status. Regards, Mohit On Tue, May 11, 2021 at 3:22 PM Ash Wilson wrote: > Hi Mohit, > I'm a little late to the discussion, so all apologies if I'm > missing something... > It looks like what you're going for is the adoption of CT logs as a client > certificate discovery method, to make revocation checks more > straightforward. > > A couple of thoughts, for your consideration: > > * CT logs can be quite revealing and suppliers may be hesitant to put > device certificates into CT logs. Mining CT logs can signal all sorts of > things about a supplier that they may not want to make public. For > instance, the total number of devices currently in the field, as well as > the frequency of new identity creation, may be useful information to a > competitor. Parsing a CT log would be a really easy way to get that > information. > > * If you want discoverability for certificates without making the entire > fleet easy to enumerate, consider the work we're doing in the DANISH BoF ( > https://datatracker.ietf.org/wg/danish/about/). We're looking to make > entity and CA certificates discoverable via DNS, for MTLS authentication > and object security use cases. This proposal could make your revocation > checks easier, and it's more performant than querying a hosted CT log. This > can also mitigate naming collisions that can occur when you allow multiple > roots of trust into your application. > > -Ash > > On Tue, May 11, 2021 at 1:38 PM Mohit Sahni wrote: > >> Hi All, >> Thanks for providing feedback regarding checking CT for Client >> certificate in MTLS connections, it looks like that we agree to come >> up with specs for this. Further, it should be doable using the >> existing TLS 1.3 protocol without any changes as David and Ryan >> commented. I will write up an Internet-draft and get back to the group >> soon. >> >> Please feel free to share any other use cases you might have for >> validating CT for client certificates in MTLS connections. >> >> Regards, >> Mohit >> >> On Mon, May 10, 2021 at 6:55 PM Mohit Sahni wrote: >> > >> > On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi >> wrote: >> > > >> > > >> > > >> > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni >> wrote: >> > >> >> > >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi >> wrote: >> > >> > >> > >> > >> > >> > >> > >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni >> wrote: >> > >> >> >> > >> >> 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: >> > >> >
Re: [TLS] DTLS RRC and heartbeat
Just want to highlight one more issue with using the original extension, many network security devices have threat signatures to identify the heartbeat extension in packet streams and they will block the sessions that match the signatures. On Thu, Oct 21, 2021 at 7:31 AM Hanno Böck wrote: > On Thu, 21 Oct 2021 10:35:54 +0100 > Thomas Fossati wrote: > > > One problem is - as Hannes put it - that heartbeat has a "somewhat > > tricky history", making its marketing a slightly intricate operation, > > and the code reuse story a bit more complicated than desired (see for > > example [3]). > > I think there were a few things that went spectacularly wrong with the > original heartbeat extension. Some of them are implementation issues > (like merging code without proper review and testing), but others are in > the spec itself. > > I think this boils down to two things that added unnecessary > complexity, which is always bad in security: > 1. The use cases were all UDP, but the extension was defined for both >UDP and TCP for no good reason. > 2. The extension contained a completely unnecessary length-encoded >message that was sent forth and back. That's a very risky >construction in terms of memory safety. > > I feel this may be enough justification to define a hearbeat-simplified > spec that doesn't have these problems. > If you decide to go with the old heartbeat extension then I'd still > wish you at least adress 1. I think many people have just compiled > openssl without heartbeat, which is a good thing as long as it's not > used anyway. If it gets used in DTLS then at least make sure that > doesn't mean it also has to be enabled in TCP-based normal TLS at the > same time. > > -- > Hanno Böck > https://hboeck.de/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Hi, > So for the new BCP, we have three options: > > Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also > TLS 1.2 implementations) to fail the handshake if the OCSP response is > missing or invalid. (As far as we can tell, RFC 8446 is silent on this.) > Remove the whole discussion of OCSP, saying that in its current form it’s not > adding value. > Maintain the status quo, where many people implement OCSP on the server side, > but clients rarely benefit. > I don't think that OCSP is not adding value in its current form. I have seen a lot of OCSP implementations with hard fail, especially on the server side for authenticating clients using private PKI certificates. Although OCSP does not add much value on the client side as it's a bit fragile for public PKI and client side checks because of the matrix of multiple OCSP status producers and consumers at scale. -Mohit ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
