Re: [lamps] The Status of OCSP and its future

[Tomas Gustavsson <[e-mail]>]

Hi Max,

On 2019-10-25 21:30, Dr. Pala wrote:
> Hi Tomas,
> 
> On 10/25/19 12:52 AM, Tomas Gustavsson wrote:
>> On 2019-10-24 17:01, Dr. Pala wrote:
>>> Hi All,
>>>
>>> I just wanted to start the conversation around the status of revocation
>>> [...]
>>> today, the larger the PKI is, the higher the costs of providing a good
>>> revocation infrastructure is.
>> As there are many PKIs today with 100M+ entities, some with and some
>> without revocation infrastructure, I think it's a bit too broad claim
>> for all use cases.
>> It is certainly true of all operations, the larger the scale the larger
>> infrastructure costs usually are, where OCSP I'd say is generally a very
>> minor part.
>> It differs from use case to use case though, I think it would be good
>> for the discussion to provide more details on your problematic use case,
>> architecture, use pattern etc. Many things are use case and
>> implementation choice specific.
> 
> This is a good point - very practical approach. A sample use-case is our
> industry (Cable). In particular, in our industry, we leverage PKIs to
> secure the communication in our networks: each Cable Modem and DVRs come
> with one or more certificates from our infrastructure. This covers all
> modems from all vendors from all operators.
> 
> Our Network, though, are going through radical changes that are aimed at
> providing the 10Gig platform we just released the standard for. In
> particular, the new architectures will see an increasing number of
> "entities" that require authentication.
> 
> As you can see, our PKI tend to be larger than what you typically see in
> the Web PKI (quite small in comparison - even combining all providers),
> therefore improving the efficiency and reducing the costs is a big win
> for the industry in general and for the users since we can now provide
> OCSP responses with shorter validity periods, thus reducing the risk
> level of our Access Networks.
> 
> This is not the only use-case, though.
> 
> Many IoT environments are starting to use digital certificates for
> authentication at a scale. Some environments, like the Power Grid, are
> already deploying solutions that use certificates to protect the
> communication up to the customers' premises.
> 
> Another use-case that I am bringing forward is Cellular. In particular,
> we already have standardized the use of certificates in some
> environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by
> freeing the network authentication from the need of a physical SIM (and
> associated licensing costs) we will see more and more devices (e.g., Fix
> and Industrial) using this technology.

These are all good examples of where PKI is used. Perhaps I am too eager
to quickly dive into technical details :-). What I was looking for was
some sort of calculations in the cost today using current technologies,
and the possible gains.

For example, (a very speculative one so please forgive my ignorance. I
am quite familiar with telecom and smart metering, but not with cable
modems):
- 100M set top boxes
- 100 media servers
Each set top box talks to media servers, load balanced.
Mutual TLS authentication, and revocation checks on all certificates
OCPS response lifetime 24h
Certificate lifetime of 1 year, renewal after 7 months

We will have somewhere around 150M certificates active. Servers can use
OCSP stapling, hence only 100 OCSP requests per day.
Each server may have contact with all set top boxes during an evening,
so each server has to make 150M OCSP requests per day. Servers cache
responses and don't make the same request twice if it already have a
fresh response. Everyone start their set top box during a two hour
window in the evening, so 150M*100/7200 OCSP requests must be handled
per second during this two hour window (it's almost 2M/second). Is this
something that you are thinking about where OCSP does not scale enough?

It is more about being able to respond quickly enough than to provision
the revocation information to OCSP responders though, so I'm not sure I
got the problem picture clear still.

> 
> This said, I think that reducing the costs of providing revocation
> information is a good goal in general and can help reducing
> authentication risks by providing shorter validity responses.
> 
>>> Our approach stem from two practical considerations: the occasion to
>>> provide optimized responses for the non-revoked case, and the
>>> [...]
>>>     planet :D
>> What could a "range" of certificates be based on?
>> (I consider sequential serialnumbers to be dead by now)
> 
> Our current approach is very simple. Take a CRL and produce (a) one
> response for each revoked certificate, and (b) one response for each
> range between revoked serial numbers. For example, if you have the
> following serial numbers revoked { 3, 5, 12 }, then you would sign 3
> responses for the 3 revoked certificates, plus the response from "0" to
> "3", two responses for the gaps between {3 and 5} and {5 and 12}, plus
> the last response for 5+. In this case, the number of revoked
> certificates is 3 and the number of signed responses is 2N + 1 = { 3
> revoked } + { 1 from 0 to the first entry } + { 2 gaps } + { 1 from last
> to infinity } = 7
> 
> Therefore, with this approach, if you are good at keeping the number of
> revoked certificates low, you can see how efficient this technique can
> be - especially when you revoked/valid certificate ratio is very low.

I think relying on sequential serialnumbers to be a big risk. It assumes
a lot of the PKI implementation, which may not be true. It is certainly
not true for the Web PKI, and also not for the IoT, Enterprise and smart
grid deployments we have been involved with. Any standard should not
rely on such PKI implementation details.

> 
>>>   * /*Providing Full Chain responses.*/ Although single OCSP responders
>>>     can be authoritative for their own CA only, they can attach the
>>>     responses for the full chain as additional data. If we add this
>>>     possibility, then a single OCSP request can provide the
>>>     client/server with the full chain of certificates up to the Root.
>>>     This might be tricky in complex scenarios where cross-certification
>>>     is used, but it would definitely work for the Web PKI and IoT use cases.
>> If extra round-tripping is needed it is certainly a concern. This is
>> also valid and discussed in the Web PKI case.
> It is to be mentioned that providing the full chain is possible today -
> however, no clients I know leverages this option. This, I think, it is
> because of several factors (i.e., trust model, AIA in certificates,
> etc.) that, if you are interested, we can explore separately.
>>> Given these considerations - and the fact that large PKIs are being
>>> deployed, today, for the IoT case - we would like to start the
>>> discussion around the current status of OCSP and possibly work on a
>>> proposal for moving forward with a more efficient protocol.
>> We do se working use cases with OCSP for huge number of devices, but in
>> IoT it's all use case dependent so I'm interested in more on your use case.
> 
> I hope that I provided you with some compelling scenarios here - I think
> that by optimizing the provisioning of revocation information we can
> help not only our specific use cases, but also the deployment of
> revocation information infrastructures that are low-cost for
> environments where using CDNs, Load Balancers, etc. is not an option
> because of the cost :D
> 
> Thanks for the reply - I do really appreciate the feedback!
> 
> Cheers,
> Max
> 
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>