Certificate Transparency for Client certificate in MTLS handshake

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Melinda Shore-4
On 5/9/21 9:13 AM, Mohit Sahni wrote:> 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).
Both approaches seem reasonable/obvious, although the OCSP-based
one seems to have a few potential issues (both around stapling and
around spotty implementation of the use of OCSP for client cert status
checking).  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.  In the seven years that trans has
been up and running this has received nearly no discussion, even
in passing, and if I recall correctly, no drafts and no agenda
time in meetings.

Melinda

--
Melinda Shore
[hidden email]

Software longa, hardware brevis

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Ryan Sleevi-3
In reply to this post by Mohit Sahni


On Sun, May 9, 2021 at 1:14 PM Mohit Sahni <[hidden email]> 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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Salz, Rich
In reply to this post by Melinda Shore-4
>  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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
In reply to this post by Ryan Sleevi-3
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 <[hidden email]> wrote:

>
>
>
> On Sun, May 9, 2021 at 1:14 PM Mohit Sahni <[hidden email]> 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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
In reply to this post by Salz, Rich
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
<rsalz=[hidden email]> 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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

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

Avamander
In reply to this post by Salz, Rich
> faces would seem to be lack of demand on the part of folks who consume client certificates.
> 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.

With the relatively slow adoption of the EU's eIDAS legislation and thus national PKIs, the demand will probably grow, but within a decade. But it's unlikely that countries themselves will show any interest in participating in this process because the adoption of CT itself is far away.

My humble prediction is that in a decade people will finally start using CT in the context of MTLS and find it somehow broken, that is if it's not taken into account right now. 

On Mon, May 10, 2021 at 4:04 PM Salz, Rich <rsalz=[hidden email]> 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.


_______________________________________________
Trans mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Ryan Sleevi-3
In reply to this post by Mohit Sahni


On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

David Benjamin
Mechanically on the TLS side, we already aligned the client and server certificate flows in TLS 1.3. TLS 1.3 already allows signed_certificate_timestamp in the CertificateRequest message. So basically what you said in Approach 1, except there's no need for the server to condition the CertificateRequest extension on a ClientHello extension. The ClientHello -> (server)Certificate and CertificateRequest -> (client)Certificate flows happen independently. Same with status_request for OCSP. So I don't believe you need any TLS protocol changes here.

Of course, that is purely about where to stick the bytes in TLS. Whether and how to use those bytes in your organization's private client-certificate-specific PKI is a more complex question and I'll defer to what others have said on the thread here.

On Mon, May 10, 2021 at 11:42 AM Ryan Sleevi <[hidden email]> wrote:


On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
In reply to this post by Ryan Sleevi-3
On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:

>
>
>
> On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Ryan Sleevi-3


On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[hidden email]> wrote:
On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:
>
>
>
> On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.

In the context of CT implementations, delivering via OCSP means delivering via OCSP stapling. This is by design - to ensure everything is provided in-band during connection establishment.

The server fetching an OCSP response and using the SCTs from that is no different than if the server simply looked up the certificate in the CT Log’s entries: it’s an active dependency on a 3P service during connection establishment, which CT intentionally worked to avoid.

This is why they’re treated as equivalent: in every CT-verifying implementation today, OCSP support means stapling.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <[hidden email]> wrote:

>
>
>
> On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[hidden email]> wrote:
>>
>> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.
>
>
> In the context of CT implementations, delivering via OCSP means delivering via OCSP stapling. This is by design - to ensure everything is provided in-band during connection establishment.
>
> The server fetching an OCSP response and using the SCTs from that is no different than if the server simply looked up the certificate in the CT Log’s entries: it’s an active dependency on a 3P service during connection establishment, which CT intentionally worked to avoid.
>
> This is why they’re treated as equivalent: in every CT-verifying implementation today, OCSP support means stapling.

Thanks for the clarification Ryan, now it all makes a lot of sense.
Please excuse my ignorance in this regard.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
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 <[hidden email]> wrote:

>
> On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <[hidden email]> wrote:
> >
> >
> >
> > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[hidden email]> wrote:
> >>
> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.
> >
> >
> > In the context of CT implementations, delivering via OCSP means delivering via OCSP stapling. This is by design - to ensure everything is provided in-band during connection establishment.
> >
> > The server fetching an OCSP response and using the SCTs from that is no different than if the server simply looked up the certificate in the CT Log’s entries: it’s an active dependency on a 3P service during connection establishment, which CT intentionally worked to avoid.
> >
> > This is why they’re treated as equivalent: in every CT-verifying implementation today, OCSP support means stapling.
>
> Thanks for the clarification Ryan, now it all makes a lot of sense.
> Please excuse my ignorance in this regard.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Ash Wilson
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <[hidden email]> wrote:
> >
> >
> >
> > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[hidden email]> wrote:
> >>
> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.
> >
> >
> > In the context of CT implementations, delivering via OCSP means delivering via OCSP stapling. This is by design - to ensure everything is provided in-band during connection establishment.
> >
> > The server fetching an OCSP response and using the SCTs from that is no different than if the server simply looked up the certificate in the CT Log’s entries: it’s an active dependency on a 3P service during connection establishment, which CT intentionally worked to avoid.
> >
> > This is why they’re treated as equivalent: in every CT-verifying implementation today, OCSP support means stapling.
>
> Thanks for the clarification Ryan, now it all makes a lot of sense.
> Please excuse my ignorance in this regard.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls


--

Ash Wilson | Technical Director

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
> On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <[hidden email]> wrote:
> >
> >
> >
> > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[hidden email]> wrote:
> >>
> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[hidden email]> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <[hidden email]> 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.
> >
> >
> > In the context of CT implementations, delivering via OCSP means delivering via OCSP stapling. This is by design - to ensure everything is provided in-band during connection establishment.
> >
> > The server fetching an OCSP response and using the SCTs from that is no different than if the server simply looked up the certificate in the CT Log’s entries: it’s an active dependency on a 3P service during connection establishment, which CT intentionally worked to avoid.
> >
> > This is why they’re treated as equivalent: in every CT-verifying implementation today, OCSP support means stapling.
>
> Thanks for the clarification Ryan, now it all makes a lot of sense.
> Please excuse my ignorance in this regard.

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls


--

Ash Wilson | Technical Director

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls