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

From: Mohit Sahni <[email-masked]>
Date: Sun, 9 May 2021 10:13:42 -0700

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

---

From: Melinda Shore <[email-masked]>
Date: Sun, 9 May 2021 13:22:20 -0800

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
[email-masked]

Software longa, hardware brevis

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 9 May 2021 18:20:47 -0400

> 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.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 May 2021 13:03:35 +0000

>  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.

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 10 May 2021 06:43:35 -0700

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 <[email-masked]> wrote:
> 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:
>
> 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.

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 10 May 2021 06:50:14 -0700

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=[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Avamander <[email-masked]>
Date: Mon, 10 May 2021 16:55:32 +0300

> 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=
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 10 May 2021 11:41:47 -0400

> 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

---

From: David Benjamin <[email-masked]>
Date: Mon, 10 May 2021 12:54:43 -0400

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.

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 10 May 2021 12:23:06 -0700

On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <[email-masked]> wrote:
> 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.
>
> [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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 10 May 2021 16:14:39 -0400

On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <[email-masked]> wrote:

> > Right, I can understand the temptation to consider OCSP Stapling as a
> more attractive solution, because it relies on the CA taking the requisite

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.

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 10 May 2021 18:55:27 -0700

On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <[email-masked]> wrote:
> 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.

---

From: Mohit Sahni <[email-masked]>
Date: Tue, 11 May 2021 13:37:13 -0700

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

---

From: Ash Wilson <[email-masked]>
Date: Tue, 11 May 2021 15:22:05 -0700

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 <[email-masked]> wrote:

> > >> > 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
> > >> > 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
> > > 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

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

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.

---

From: Mohit Sahni <[email-masked]>
Date: Tue, 11 May 2021 15:59:27 -0700

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 <[email-masked]> wrote:

>> > >> > Right, I can understand the temptation to consider OCSP Stapling
>> as a more attractive solution, because it relies on the CA taking the
>> > >> > 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