Subject: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare)

From: "Dr. Pala" <[email-masked]>
Date: Tue, 19 Nov 2019 21:10:54 +0800

Hi Nick, all,

at the end of the second presentation on lowering the costs of 
revocation, if I am not mistaken, your question/comment (Nick) was about 
the fact that Cloudflare hosts / serve most of the cached OCSP responses 
and that the system does not have issues.

I am not sure if this comment is pertinent to what we are trying to 
solve here... let me elaborate a bit more.

The work we have been doing around the proposed topic of work is aimed 
at /_lowering the cost of *generating* and *distributing* these large 
volumes of signed data_/ when there is actually no need for that. By 
optimizing the protocol to provide range responses (or other methods, if 
we decide to go with a different approaches), we can reduce the number 
of signatures needed from a CA and their distribution - very expensive 
operations.

In other words, the proposal is /_not aimed at fixing any caching 
issues_/ because, as you noticed in your comment, that works just fine. 
The proposal at hand, instead, is about fixing a problem that CAs are 
facing today - high costs of deploying and running such systems.

On the other hand, your comment made me think about the caching service 
you mentioned and its associated costs.

Is it a service for which your company charge CAs ? If so, would you be 
able to share what are currently the costs incurred by CAs to leverage 
your service ? (I totally understand if you are not willing to - after 
all, this is usually the secret sauce :D)

Last but not least, I also would like to point out that optimizing the 
revocation can also help open-source communities, small companies, 
universities, non-profit, etc. by enabling them to deploy cost-efficient 
systems that can provide good quality of service using less resources 
(computational, storage, network).

Please let me know,

Cheers,
Max

P.S.: If we could combine this idea with OCSP over DNS, we could really 
provide access to revocation technology for everybody, not just who can 
afford the price. Unfortunately we know how that discussion went, and I 
still think it is a very evident mistake not doing it  (I am still 
working on this in my spare time - I think it is of enormous value for 
emerging countries to have access to cheap secure technologies and, in 
my opinion, IETF is dropping / has dropped the ball on this for 
not-so-honorable reasons, I suspect...). I hope We can fix it in the 
open-source community.

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 20 Nov 2019 13:07:48 +0800

Hi Max,

Thanks for your clarification. I now understand the work is aimed at
optimizing the number of signatures by the CA's OCSP responder and the
number of bytes of unique OCSP data.

Currently, the number of OCSP signatures the CA needs to do is linear in
the number of active certificates. This proposal changes this so that the
number of signatures is linear in the number of revocations of active
certificates. It's conceptually similar to NSEC in that way: it's a cover
proposal in which the artifacts are constant size, but require a linear
number signatures in the size of the revocation set. Contrast this with
CRLs, which require a constant number of signatures, but are linear in the
size of the revocation set. So maybe the goals could be better phrased in
terms of *lowering the cost of generating compared to OCSP
and distributing compared to CRLs*.

This proposal implies a middle-ground PKI deployment that has enough
revocations for CRL to be inefficient but not enough to cause the negative
space of the serial number to be of the same order as the number of
certificates. It would be great to see examples of PKIs that motivate this
optimization, which is why I suggested that data could help.

I should also note that while this proposal reduces the number of OCSP
signatures (which can be on the order of 104 signatures for 2-year certs),
the impact is less dramatic for CAs that issue shorter-lived certs. For
example, Let's Encrypt only signs around 13 OCSP responses for each of
their 3-month certificates.

Nick

On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <[email-masked]> wrote:

> Hi Nick, all,
>
> at the end of the second presentation on lowering the costs of revocation,
> if I am not mistaken, your question/comment (Nick) was about the fact that
> Cloudflare hosts / serve most of the cached OCSP responses and that the
> system does not have issues.
>
> I am not sure if this comment is pertinent to what we are trying to solve
> here... let me elaborate a bit more.
>
> The work we have been doing around the proposed topic of work is aimed at *lowering
> the cost of generating and distributing these large volumes of signed data*
> when there is actually no need for that. By optimizing the protocol to
> provide range responses (or other methods, if we decide to go with a
> different approaches), we can reduce the number of signatures needed from a
> CA and their distribution - very expensive operations.
>
> In other words, the proposal is *not aimed at fixing any caching issues*
> because, as you noticed in your comment, that works just fine. The proposal
> at hand, instead, is about fixing a problem that CAs are facing today -
> high costs of deploying and running such systems.
>
> able to share what are currently the costs incurred by CAs to leverage your
> service ? (I totally understand if you are not willing to - after all, this
> is usually the secret sauce :D)
>
> still think it is a very evident mistake not doing it  (I am still working
> on this in my spare time - I think it is of enormous value for emerging
> countries to have access to cheap secure technologies and, in my opinion,
> IETF is dropping / has dropped the ball on this for not-so-honorable
> reasons, I suspect...). I hope We can fix it in the open-source community.
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
>

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 20 Nov 2019 14:47:03 +0800

Hi Nick,

thanks for the reply. My comments are inline...

> number of bytes of unique OCSP data.
Yes, that is correct. The other optimization is about the ability to 
provide responses for the whole chain in a single message.
> Currently, the number of OCSP signatures the CA needs to do is linear 
> in the number of active certificates. This proposal changes this so 
> that the number of signatures is linear in the number of revocations 
> of active certificates. It's conceptually similar to NSEC in that way: 
> it's a cover proposal in which the artifacts are constant size, but 
> require a linear number signatures in the size of the revocation set. 
> Contrast this with CRLs, which require a constant number of 
> signatures, but are linear in the size of the revocation set. So maybe 
> the goals could be better phrased in terms of _/lowering the cost of 
> /*generating*/ compared to OCSP and /*distributing*/ compared to CRLs/_.
>
I am not sure I follow. In PKIs, today, we use both mechanisms. This is 
because usually the CRLs are used as a backup mechanism for OCSP - we 
also need to support both because of Certification Policies (exactly as 
in the Internet PKI environment), therefore it is not a choice :D The 
proposed approach can be used to (a) limit the amount of data that needs 
to be generated, stored, and transferred when pre-computing responses, 
and (b) to compute all responses and serve them from memory - even small 
instances without any hardware acceleration could achieve reasonable 
performances (also for shorter validity periods in responses).
> revocations for CRL to be inefficient but not enough to cause the 
> negative space of the serial number to be of the same order as the 
> number of certificates. It would be great to see examples of PKIs that 
> motivate this optimization, which is why I suggested that data could help.

Technically, you are correct. If we could predict the size of CRLs, we 
could potentially try to understand what that threshold is. However, as 
I explained in the presentation, the size is fairly unpredictable. That 
is why we primarily use OCSP today.

> signatures (which can be on the order of 104 signatures for 2-year 
> certs), the impact is less dramatic for CAs that issue shorter-lived 
> certs. For example, Let's Encrypt only signs around 13 OCSP responses 
> for each of their 3-month certificates.

That is correct, the impact is less with short-lived certificates 
because in those environment, the population of active certificates is 
usually smaller. If the population is still large, you still have the 
same problem.

You mention that your OCSP responses have a 7 days validity, correct ? 
My question is: which considerations went into deciding such a large 
validity period for the OCSP responses (7 days) ? Maybe costs 
considerations drove the decision ? From a security standpoint, such 
long validity periods blinds clients from detecting revocation that 
might happen during the 7-days validity period (the problem is worse now 
with the deployment of OCSP stapling because clients do not fetch fresh 
responses at connect time, AFAIK, if stapling is supported). I would 
expect that few minutes validity windows or maybe few hours would be a 
better choice - but how much does that cost to Let's Encrypt ?

The Cable industry has used certificates, for few decades now, for 
different purposes - as a hardware certification tool and to secure our 
networks - in this environment, the typical life-span of a certificate 
is many years (up to 20) and it is tied to the envisioned life-span of 
the device (no renewal). As you can see, in our environment, CRLs will 
never be an option and OCSP simply costs too much (for an infrastructure 
that, over all, has an active population of several hundreds million of 
active certificates - we might be even beyond that with just the three 
OpenCable, PacketCable, and DOCSIS).

Ultimately, we need to work on the solution so that we can have our 
vendors to integrate it in their products, like CableModes, that are 
going to be deployed (and provide internet connectivity) for hundreds of 
millions of households for the next 10 to 20 years. We need to lower the 
security risks associated with the infrastructures that brings Internet 
to many of us - revocation is important to prevent possible compromises 
to go undetected. I think that everybody who has Cable should support 
this work that is going to directly impact them for many years.

Cheers,
Max

P.S.: I also have other personal motivations for this work. I think that 
this is also the right thing to do for non-technical reasons - I come 
from the OpenSource world that so much has give for the success of the 
Internet but where there is no money. More efficient technologies could 
be leveraged by communities around the world who deserve good security 
but costs get in the way. I know it is not a technical detail, but I 
think we shall always try to have these considerations in our minds - 
making the world a better place and less wasteful (energy) is an 
amendable goal in general and emerging communities could really benefit 
from our work.

> On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Nick, all,
>
>     revocation, if I am not mistaken, your question/comment (Nick) was
>     about the fact that Cloudflare hosts / serve most of the cached
>     OCSP responses and that the system does not have issues.
>
>     I am not sure if this comment is pertinent to what we are trying
>     to solve here... let me elaborate a bit more.
>
>     The work we have been doing around the proposed topic of work is
>     aimed at /_lowering the cost of *generating* and *distributing*
>     these large volumes of signed data_/ when there is actually no
>     need for that. By optimizing the protocol to provide range
>     responses (or other methods, if we decide to go with a different
>     approaches), we can reduce the number of signatures needed from a
>     issues_/ because, as you noticed in your comment, that works just
>     fine. The proposal at hand, instead, is about fixing a problem
>     that CAs are facing today - high costs of deploying and running
>     such systems.
>
>     On the other hand, your comment made me think about the caching
>     service you mentioned and its associated costs.
>
>     Is it a service for which your company charge CAs ? If so, would
>     you be able to share what are currently the costs incurred by CAs
>     to leverage your service ? (I totally understand if you are not
>     willing to - after all, this is usually the secret sauce :D)
>
>     Last but not least, I also would like to point out that optimizing
>     the revocation can also help open-source communities, small
>     companies, universities, non-profit, etc. by enabling them to
>     deploy cost-efficient systems that can provide good quality of
>     service using less resources (computational, storage, network).
>
>     Please let me know,
>
>     Cheers,
>     Max
>
>     P.S.: If we could combine this idea with OCSP over DNS, we could
>     really provide access to revocation technology for everybody, not
>     just who can afford the price. Unfortunately we know how that
>     discussion went, and I still think it is a very evident mistake
>     not doing it  (I am still working on this in my spare time - I
>     think it is of enormous value for emerging countries to have
>     access to cheap secure technologies and, in my opinion, IETF is
>     dropping / has dropped the ball on this for not-so-honorable
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 26 Nov 2019 05:42:45 -0800

Hi Max,

What's the current proposal? The draft <https://tools.ietf.org/html/draft-pala-ocspv2-00> doesn't appear to contain details beyond the notion of providing ranges and information about the entire chain, and it doesn't seem to address the issues raised in the PKIX and LAMPS discussions linked here <https://datatracker.ietf.org/meeting/106/materials/agenda-106-secdispatch-03>.

At Apple, we also cache OCSP responses in a compressed form, i.e. in Bloom filters. Having the option to receive CRLs in a compressed format like that would definitely be more efficient for us. I'm not convinced that ranges would be as helpful. CRLs are helpful when someone is compiling an entire catalog of revoked certificates. OCSP is helpful when you want to check the revocation status of one particular certificate. If OCSP is instead a hybrid of these two approaches, this assumes that the client is going to want data on the other certificates in the range they receive (many of which won't even exist, since, as someone commented in the pkix thread, serial numbers are often (usually?) randomized). I'm not sure how often that additional revocation information is actually going to be useful to the client. Statistics on that is the sort of data that would be helpful in evaluating this proposal. If it turns out, for instance, that providing ranges ends up saving only, say, 0.1% of OCSP requests, it probably wouldn't be worth the effort.

As for returning revocation data for the entire chain, the question must be asked: which chain? In some cases, certificates are cross-signed, and so there is no one chain to provide revocation data for. Is the client effectively going to delegate finding the best chain to the OCSP responder? I'm not sure that's in the client's best interest, and I'm not sure OCSP responders are going to want to bother handling that.

Carrick

> On Nov 20, 2019, at 2:47 PM, Dr. Pala <[email-masked]> wrote:
> 
> Hi Nick,
> 
>> Thanks for your clarification. I now understand the work is aimed at optimizing the number of signatures by the CA's OCSP responder and the number of bytes of unique OCSP data.
>> 
> Yes, that is correct. The other optimization is about the ability to provide responses for the whole chain in a single message.
>> Currently, the number of OCSP signatures the CA needs to do is linear in the number of active certificates. This proposal changes this so that the number of signatures is linear in the number of revocations of active certificates. It's conceptually similar to NSEC in that way: it's a cover proposal in which the artifacts are constant size, but require a linear number signatures in the size of the revocation set. Contrast this with CRLs, which require a constant number of signatures, but are linear in the size of the revocation set. So maybe the goals could be better phrased in terms of lowering the cost of generating compared to OCSP and distributing compared to CRLs.
>> 
> I am not sure I follow. In PKIs, today, we use both mechanisms. This is because usually the CRLs are used as a backup mechanism for OCSP - we also need to support both because of Certification Policies (exactly as in the Internet PKI environment), therefore it is not a choice :D The proposed approach can be used to (a) limit the amount of data that needs to be generated, stored, and transferred when pre-computing responses, and (b) to compute all responses and serve them from memory - even small instances without any hardware acceleration could achieve reasonable performances (also for shorter validity periods in responses).
>> This proposal implies a middle-ground PKI deployment that has enough revocations for CRL to be inefficient but not enough to cause the negative space of the serial number to be of the same order as the number of certificates. It would be great to see examples of PKIs that motivate this optimization, which is why I suggested that data could help.
> Technically, you are correct. If we could predict the size of CRLs, we could potentially try to understand what that threshold is. However, as I explained in the presentation, the size is fairly unpredictable. That is why we primarily use OCSP today.
> 
>> 
>> I should also note that while this proposal reduces the number of OCSP signatures (which can be on the order of 104 signatures for 2-year certs), the impact is less dramatic for CAs that issue shorter-lived certs. For example, Let's Encrypt only signs around 13 OCSP responses for each of their 3-month certificates.
> That is correct, the impact is less with short-lived certificates because in those environment, the population of active certificates is usually smaller. If the population is still large, you still have the same problem.
> 
> You mention that your OCSP responses have a 7 days validity, correct ? My question is: which considerations went into deciding such a large validity period for the OCSP responses (7 days) ? Maybe costs considerations drove the decision ? From a security standpoint, such long validity periods blinds clients from detecting revocation that might happen during the 7-days validity period (the problem is worse now with the deployment of OCSP stapling because clients do not fetch fresh responses at connect time, AFAIK, if stapling is supported). I would expect that few minutes validity windows or maybe few hours would be a better choice - but how much does that cost to Let's Encrypt ?
> 
> The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS).
> 
> Ultimately, we need to work on the solution so that we can have our vendors to integrate it in their products, like CableModes, that are going to be deployed (and provide internet connectivity) for hundreds of millions of households for the next 10 to 20 years. We need to lower the security risks associated with the infrastructures that brings Internet to many of us - revocation is important to prevent possible compromises to go undetected. I think that everybody who has Cable should support this work that is going to directly impact them for many years. 
> 
> Cheers,
> Max
> 
> P.S.: I also have other personal motivations for this work. I think that this is also the right thing to do for non-technical reasons - I come from the OpenSource world that so much has give for the success of the Internet but where there is no money. More efficient technologies could be leveraged by communities around the world who deserve good security but costs get in the way. I know it is not a technical detail, but I think we shall always try to have these considerations in our minds - making the world a better place and less wasteful (energy) is an amendable goal in general and emerging communities could really benefit from our work.
> 
> 
> 
>> On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Nick, all,
>> 
>> at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues.
>> 
>> I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more.
>> 
>> The work we have been doing around the proposed topic of work is aimed at lowering the cost of generating and distributing these large volumes of signed data when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations.
>> 
>> In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems.
>> 
>> On the other hand, your comment made me think about the caching service you mentioned and its associated costs. 
>> 
>> Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D)
>> 
>> Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network).
>> 
>> Please let me know,
>> 
>> Cheers,
>> Max
>> 
>> P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it  (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community.
>> 
>> -- 
>> Best Regards,
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> _______________________________________________
> Secdispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Nov 2019 06:25:53 -0800

It's probably useful to start with a clear problem statement. if I
understood Max's presentation correctly, it's that it's too expensive to
compute all the OCSP signatures.  I'm not sure I'm persuaded that that's
true, as public key signatures are very fast (especially if you use ECDSA),
and even the largest public CAs don't actually have that many certificates
on the grand scheme of things [0]. However, to the extent to which it is
true, it seems like the natural response would be to move to a batch
signature scheme, such as the one David Benjamin proposed for TLS [1]. This
would have the advantage that it doesn't require any new protocol
definition or reasoning, it's just a drop-in for the existing signatures.

-Ekr

[0] Let's Encrypt has about 10^8 certificates active.
[1] https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00

On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle <cbartle891=
[email-masked]> wrote:

> Hi Max,
>
> What's the current proposal? The draft
> <https://tools.ietf.org/html/draft-pala-ocspv2-00> doesn't appear to
> contain details beyond the notion of providing ranges and information about
> the entire chain, and it doesn't seem to address the issues raised in the
> PKIX and LAMPS discussions linked here
> <https://datatracker.ietf.org/meeting/106/materials/agenda-106-secdispatch-03>
> .
>
> At Apple, we also cache OCSP responses in a compressed form, i.e. in Bloom
> filters. Having the option to receive CRLs in a compressed format like that
> would definitely be more efficient for us. I'm not convinced that ranges
> would be as helpful. CRLs are helpful when someone is compiling an entire
> catalog of revoked certificates. OCSP is helpful when you want to check the
> revocation status of one particular certificate. If OCSP is instead a
> hybrid of these two approaches, this assumes that the client is going to
> want data on the other certificates in the range they receive (many of
> which won't even exist, since, as someone commented in the pkix thread,
> serial numbers are often (usually?) randomized). I'm not sure how often
> that additional revocation information is actually going to be useful to
> the client. Statistics on that is the sort of data that would be helpful in
> evaluating this proposal. If it turns out, for instance, that providing
> ranges ends up saving only, say, 0.1% of OCSP requests, it probably
> wouldn't be worth the effort.
>
> As for returning revocation data for the entire chain, the question must
> be asked: which chain? In some cases, certificates are cross-signed, and so
> there is no one chain to provide revocation data for. Is the client
> effectively going to delegate finding the best chain to the OCSP responder?
> I'm not sure that's in the client's best interest, and I'm not sure OCSP
> responders are going to want to bother handling that.
>
> Carrick
>
>
>
> because usually the CRLs are used as a backup mechanism for OCSP - we also
> need to support both because of Certification Policies (exactly as in the
> Internet PKI environment), therefore it is not a choice :D The proposed
> approach can be used to (a) limit the amount of data that needs to be
> generated, stored, and transferred when pre-computing responses, and (b) to
> compute all responses and serve them from memory - even small instances
> without any hardware acceleration could achieve reasonable performances
> (also for shorter validity periods in responses).
>
> could potentially try to understand what that threshold is. However, as I
> explained in the presentation, the size is fairly unpredictable. That is
> why we primarily use OCSP today.
>
>
> That is correct, the impact is less with short-lived certificates because
> in those environment, the population of active certificates is usually
> smaller. If the population is still large, you still have the same problem.
>
> You mention that your OCSP responses have a 7 days validity, correct ? My
> question is: which considerations went into deciding such a large validity
> period for the OCSP responses (7 days) ? Maybe costs considerations drove
> the decision ? From a security standpoint, such long validity periods
> blinds clients from detecting revocation that might happen during the
> 7-days validity period (the problem is worse now with the deployment of
> OCSP stapling because clients do not fetch fresh responses at connect time,
> AFAIK, if stapling is supported). I would expect that few minutes validity
> windows or maybe few hours would be a better choice - but how much does
> that cost to Let's Encrypt ?
>
> networks - in this environment, the typical life-span of a certificate is
> many years (up to 20) and it is tied to the envisioned life-span of the
> device (no renewal). As you can see, in our environment, CRLs will never be
> an option and OCSP simply costs too much (for an infrastructure that, over
> all, has an active population of several hundreds million of active
> certificates - we might be even beyond that with just the three OpenCable,
> PacketCable, and DOCSIS).
>
> vendors to integrate it in their products, like CableModes, that are going
> to be deployed (and provide internet connectivity) for hundreds of millions
> of households for the next 10 to 20 years. We need to lower the security
> risks associated with the infrastructures that brings Internet to many of
> us - revocation is important to prevent possible compromises to go
> undetected. I think that everybody who has Cable should support this work
> that is going to directly impact them for many years.
>
> Cheers,
> Max
>
> this is also the right thing to do for non-technical reasons - I come from
> the OpenSource world that so much has give for the success of the Internet
> but where there is no money. More efficient technologies could be leveraged
> by communities around the world who deserve good security but costs get in
> the way. I know it is not a technical detail, but I think we shall always
> try to have these considerations in our minds - making the world a better
> place and less wasteful (energy) is an amendable goal in general and
> emerging communities could really benefit from our work.
>
>
>> The work we have been doing around the proposed topic of work is aimed at
>>  *lowering the cost of generating and distributing these large volumes
>> of signed data* when there is actually no need for that. By optimizing
>> the protocol to provide range responses (or other methods, if we decide to
>> go with a different approaches), we can reduce the number of signatures
>> needed from a CA and their distribution - very expensive operations.
>>
>> In other words, the proposal is *not aimed at fixing any caching issues* because,
>> as you noticed in your comment, that works just fine. The proposal at hand,
>> instead, is about fixing a problem that CAs are facing today - high costs
>> of deploying and running such systems.
>>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 26 Nov 2019 19:55:27 +0000

Hello,

I'm a big fan of the bloom filters that several browsers are deploying.
However, these filters express an aggregate of all the information across
multiple CRLs, and have some false positives due to the compression.  It
naively seems to me that creating these bloom filters based on compressed
CRLs would be a bad idea, as it would compound the errors.  But I'd love to
see or work with people on data on that, because perhaps with the proper
tuning that isn't really an issue.  So if you're using bloom filters, you
probably want to spend the time working on raw CRLs, and either way, this
proposal is of no interest to you since you're not relying on OCSP on the
client side.

However, that's not the use case that ranges really address.  Ranges are NOT
intended for clients that want the status of multiple certificates.  Indeed,
they don't work particularly well for that use case because it doesn't take
too many revocations before you have to get a bit lucky for multiple of the
certificates you are interested in to be in the same range.

The real use case is for devices that do not have the storage capacity to
take advantage of the bloom filter approach.  These clients still need OCSP
to be efficient for single certificates.  And it is, on the client end.
However, on the server end, generating individual OCSP responses and
distributing them to a CDN for every valid certificate is a significant
workload.  This is especially true because the smaller and more resource
constrained your devices are, the likelihood is you have many, many more of
them.  So it makes sense to think about how to optimize for the "most
lightbulbs are not revoked" case.

Both the generation time and the amount of CDN content that needs to be
distributed is greatly reduced by allowing range-based responses.

So again, this isn't about saving OCSP requests at all, and this proposal
has absolutely no impact on the very intelligent and forward looking
endpoint that choose to avoid OCSP requests by compressing CRLs and
replacing OCSP with local lookup.  It's designed for systems and ecosystems
who can't do that, which is not the Apple use case.

-Tim

From: Carrick Bartle <[email-masked]> 
Sent: Tuesday, November 26, 2019 8:43 AM
To: Dr. Pala <[email-masked]>
Cc: Nick Sullivan <[email-masked]>; IETF SecDispatch
<[email-masked]>; Tim Hollebeek <[email-masked]>
Subject: Re: [Secdispatch] Clarification for a question about OCSP caching
from Nick (Cloudflare)

Hi Max,

<https://datatracker.ietf.org/meeting/106/materials/agenda-106-secdispatch-0
3> .

At Apple, we also cache OCSP responses in a compressed form, i.e. in Bloom
filters. Having the option to receive CRLs in a compressed format like that
would definitely be more efficient for us. I'm not convinced that ranges
would be as helpful. CRLs are helpful when someone is compiling an entire
catalog of revoked certificates. OCSP is helpful when you want to check the
revocation status of one particular certificate. If OCSP is instead a hybrid
of these two approaches, this assumes that the client is going to want data
on the other certificates in the range they receive (many of which won't
even exist, since, as someone commented in the pkix thread, serial numbers
are often (usually?) randomized). I'm not sure how often that additional
revocation information is actually going to be useful to the client.
Statistics on that is the sort of data that would be helpful in evaluating
this proposal. If it turns out, for instance, that providing ranges ends up
saving only, say, 0.1% of OCSP requests, it probably wouldn't be worth the
effort.

As for returning revocation data for the entire chain, the question must be
asked: which chain? In some cases, certificates are cross-signed, and so
there is no one chain to provide revocation data for. Is the client
effectively going to delegate finding the best chain to the OCSP responder?
I'm not sure that's in the client's best interest, and I'm not sure OCSP
responders are going to want to bother handling that.

Carrick

On Nov 20, 2019, at 2:47 PM, Dr. Pala <[email-masked]
<mailto:[email-masked]> > wrote:

Hi Nick,

Hi Max,

Yes, that is correct. The other optimization is about the ability to provide
responses for the whole chain in a single message.

Currently, the number of OCSP signatures the CA needs to do is linear in the
number of active certificates. This proposal changes this so that the number
of signatures is linear in the number of revocations of active certificates.
It's conceptually similar to NSEC in that way: it's a cover proposal in
which the artifacts are constant size, but require a linear number
signatures in the size of the revocation set. Contrast this with CRLs, which
require a constant number of signatures, but are linear in the size of the
revocation set. So maybe the goals could be better phrased in terms of
lowering the cost of generating compared to OCSP and distributing compared
to CRLs.

Technically, you are correct. If we could predict the size of CRLs, we could
potentially try to understand what that threshold is. However, as I
explained in the presentation, the size is fairly unpredictable. That is why
we primarily use OCSP today.

I should also note that while this proposal reduces the number of OCSP
signatures (which can be on the order of 104 signatures for 2-year certs),
the impact is less dramatic for CAs that issue shorter-lived certs. For
example, Let's Encrypt only signs around 13 OCSP responses for each of their
3-month certificates.

That is correct, the impact is less with short-lived certificates because in
those environment, the population of active certificates is usually smaller.
If the population is still large, you still have the same problem.

You mention that your OCSP responses have a 7 days validity, correct ? My
question is: which considerations went into deciding such a large validity
period for the OCSP responses (7 days) ? Maybe costs considerations drove
the decision ? From a security standpoint, such long validity periods blinds
clients from detecting revocation that might happen during the 7-days
validity period (the problem is worse now with the deployment of OCSP
stapling because clients do not fetch fresh responses at connect time,
AFAIK, if stapling is supported). I would expect that few minutes validity
windows or maybe few hours would be a better choice - but how much does that
cost to Let's Encrypt ?

The Cable industry has used certificates, for few decades now, for different
purposes - as a hardware certification tool and to secure our networks - in
this environment, the typical life-span of a certificate is many years (up
to 20) and it is tied to the envisioned life-span of the device (no
renewal). As you can see, in our environment, CRLs will never be an option
and OCSP simply costs too much (for an infrastructure that, over all, has an
active population of several hundreds million of active certificates - we
might be even beyond that with just the three OpenCable, PacketCable, and
DOCSIS).

Ultimately, we need to work on the solution so that we can have our vendors
to integrate it in their products, like CableModes, that are going to be
deployed (and provide internet connectivity) for hundreds of millions of
households for the next 10 to 20 years. We need to lower the security risks
associated with the infrastructures that brings Internet to many of us -
revocation is important to prevent possible compromises to go undetected. I
think that everybody who has Cable should support this work that is going to
directly impact them for many years. 

Cheers,
Max

On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <[email-masked]
<mailto:[email-masked]> > wrote:

Hi Nick, all,

The work we have been doing around the proposed topic of work is aimed at
lowering the cost of generating and distributing these large volumes of
signed data when there is actually no need for that. By optimizing the
protocol to provide range responses (or other methods, if we decide to go
with a different approaches), we can reduce the number of signatures needed
from a CA and their distribution - very expensive operations.

In other words, the proposal is not aimed at fixing any caching issues
because, as you noticed in your comment, that works just fine. The proposal
at hand, instead, is about fixing a problem that CAs are facing today - high
costs of deploying and running such systems.

On the other hand, your comment made me think about the caching service you
mentioned and its associated costs. 

Is it a service for which your company charge CAs ? If so, would you be able
to share what are currently the costs incurred by CAs to leverage your
service ? (I totally understand if you are not willing to - after all, this
is usually the secret sauce :D)

Please let me know,

Cheers,
Max

-- 

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

-- 

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

_______________________________________________
Secdispatch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/secdispatch>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Nov 2019 18:42:58 +0100

Eric Rescorla <[email-masked]> wrote:
    > signature scheme, such as the one David Benjamin proposed for TLS [1].

This would work well for TLS.
It would be good to understand if the problems that Dr. Pala is talking about
are specifically about TLS, or if it relates to some other system common in
the cable industry.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Nov 2019 14:20:10 -0800

> are specifically about TLS, or if it relates to some other system common in

I think it's less a matter of TLS versus not TLS but rather of what you are
trying to optimize for.

If it's just signing bandwidth then this is a good solution. If it's also
network bandwidth, then perhaps less so, though we'd need to do the math.

-Ekr

---

From: Carrick Bartle <[email-masked]>
Date: Fri, 29 Nov 2019 16:02:26 -0800

> It's probably useful to start with a clear problem statement.

Agreed.

> if I understood Max's presentation correctly, it's that it's too expensive to compute all the OCSP signatures. I'm not sure I'm persuaded that that's true, as public key signatures are very fast (especially if you use ECDSA)

Although the current draft states that it "address(es) the inefficiencies of OCSPv1 by (a) providing range-based responses to optimize (reduce) the number of pre-computed responses," my understanding was that it wasn't to save on computation time necessarily, but network time and bandwidth. But actually, one common problem with OCSP is the failure to get any response at all because responders are sometimes unavailable for one reason or another. So if the client received a whole batch of revocation data instead of information only on one certificate, the client could cache and use that data instead of having to make additional OCSP requests that may never get responses.

Carrick

> , and even the largest public CAs don't actually have that many certificates on the grand scheme of things [0]. However, to the extent to which it is true, it seems like the natural response would be to move to a batch signature scheme, such as the one David Benjamin proposed for TLS [1]. This would have the advantage that it doesn't require any new protocol definition or reasoning, it's just a drop-in for the existing signatures.
> 
> -Ekr
> 
> [0] Let's Encrypt has about 10^8 certificates active..
> [1] https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 <https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00>
> On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle <cbartle891=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Max,
> 
>> On Nov 20, 2019, at 2:47 PM, Dr. Pala <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Nick,
>> 
>> thanks for the reply. My comments are inline....
>> 
>> The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS)..
>>