Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Life for Certificate Revocation Lists

letsencrypt.org

Post reply on HN
Print view View original

61–70 of 72 posts

Re: A New Life for Certificate Revocation Lists

#61

Post by OrvalWintermute »

WorldMaker wrote: post #45
OrvalWintermute wrote: post #40

Earlier quoted context omitted.

Merkle Hash Trees are the well-known solution for this, whenever they decide to update the protocols (was software patent encumbered til 2017)

It sounds close to what the article suggests Let's Encrypt is using internally to store/generate the CRL files, though the article doesn't get into a lot of technical details to tell exactly if that is the case.

No. That isn't the same.

CRLs and OCSP are about individual certificates.

The beauty of Merkle Hash Trees for validation is it permits Statements e.g.

CAx = CA2 and 156 ≤ X The statement cj indicates that the certificate with serial number X = 156 issued by CA2 has been revoked, while the certificates with serial numbers from X = 157 to X = 343 (both included) issued by CA2 have not been revoked.

From https://www.researchgate.net/publication/220066804_Certifica...

Re: A New Life for Certificate Revocation Lists

#62

Post by Thorrez »

OrvalWintermute wrote: post #61
WorldMaker wrote: post #45

Earlier quoted context omitted.

It sounds close to what the article suggests Let's Encrypt is using internally to store/generate the CRL files, though the article doesn't get into a lot of technical details to tell exactly if that is the case.

No. That isn't the same. CRLs and OCSP are about individual certificates. The beauty of Merkle Hash Trees for validation is it permits Statements e.g. CAx = CA2 and 156 ≤ X The statement cj indicates that the certificate with serial number X = 156 issued by CA2 has been revoked, while the certificates with serial numbers from X = 157 to X = 343 (both included) issued by CA2 have not been revoked. From https://www.res…

Wouldn't a CRL that lists all the revoked certificates tell you that exact same information?

Re: A New Life for Certificate Revocation Lists

#63

Post by doomrobo »

OrvalWintermute wrote: post #40
WorldMaker wrote: post #33

Earlier quoted context omitted.

The article does later state Lets Encrypt's own expected worst case is 8 GBs in one CRL file in the hopefully unlikely scenario that every unexpired certificate they manage was revoked.

Merkle Hash Trees are the well-known solution for this, whenever they decide to update the protocols (was software patent encumbered til 2017)

Merkle Hash Trees are not a solution for offline checks. You can very easily check membership in a tree if someone sends you a proof of membership. But to get a proof, you'd either have to generate it yourself (meaning you're storing the whole set anyway) or get it from a third party (ie an online lookup, which is what OCSP is). The forefront of CRL design is in set compression techniques like Ribbon filters https://arxiv.org/pdf/2103.02515.pdf

Re: A New Life for Certificate Revocation Lists

#64

Post by weinzierl »

> "They process the CRLs into a smaller format such as a Bloom filter, then push the new compressed object to all of the installed browser instances using pre-existing rapid update mechanisms. Firefox, for example, is pushing updates as quickly as every 6 hours."

Does anyone know what the rate of revocations is?

I can easily imagine a situation where it is high enough to cause a browser update every few hours. That is for every installed browser, because - as they say in the article - Browser-Summarized CRLs are "proprietary, browser-specific CRLs". Moreover there are non-browser clients which we must consider if we are to take this proposal seriously.

------

My quick back of the envelope estimation:

CRL size: 4GiB (they say in the article that it could be easily the size of a movie)

Average Cert Size: 75 bytes (first hit in Google, no idea if reliable number)

Time Span: 825 days (CRLs have only unexpired certs and ones older than 825 should all be expired)

4GiB/(75B/cert)/825days = 69141 certs/day

Sounds way too high to me. Where am I wrong?

Re: A New Life for Certificate Revocation Lists

#65

Post by lifthrasiir »

weinzierl wrote: post #64

> "They process the CRLs into a smaller format such as a Bloom filter, then push the new compressed object to all of the installed browser instances using pre-existing rapid update mechanisms. Firefox, for example, is pushing updates as quickly as every 6 hours." Does anyone know what the rate of revocations is? I can easily imagine a situation where it is high enough to cause a browser update every few hours. That i…

In the CRLite paper [1] the bandwidth cost was estimated to be ~600 KB per day. Most crucially they do not directly store certificates but only boolean flags for hashes of virtually all once-valid certificates in existence. This is made possible because of Certificate Transparency; once the signature has been verified there can be only so many hashes to check.

[1] https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland...

Re: A New Life for Certificate Revocation Lists

#66

Post by aaomidi »

mholt wrote: post #52
aaomidi wrote: post #27

Earlier quoted context omitted.

OCSP stapling increases how large the first response from the server is, increasing the time to first useful byte.

It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems). OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.* * Thi…

A few hundred bytes is a ton data for something that a lot of people don’t particularly care about, and is still broken despite OCSP stapling. People don’t have low latency, clean internet all over the world and adding something like this on top of an already pretty bloated negotiation doesn’t help.

As for the alternative not a single browser out there validates OCSP out of the box on the hot path (e.g actually waits for OCSP before proceeding)

Re: A New Life for Certificate Revocation Lists

#67

Post by OrvalWintermute »

mholt wrote: post #52
aaomidi wrote: post #27

Earlier quoted context omitted.

OCSP stapling increases how large the first response from the server is, increasing the time to first useful byte.

It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems). OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.* * Thi…

Speaking from a PKI perspective you may head towards shorter lived certificates in many use-cases, NPE / automatable re-keying being examples of that.

However, for strong PKI on a consumer or enterprise encryption/decryption device, e.g. smartcards, there is big costs associated with shortening lifetimes. Not going to fly there.

Re: A New Life for Certificate Revocation Lists

#68

Post by OrvalWintermute »

doomrobo wrote: post #63
OrvalWintermute wrote: post #40

Earlier quoted context omitted.

Merkle Hash Trees are the well-known solution for this, whenever they decide to update the protocols (was software patent encumbered til 2017)

Merkle Hash Trees are not a solution for offline checks. You can very easily check membership in a tree if someone sends you a proof of membership. But to get a proof, you'd either have to generate it yourself (meaning you're storing the whole set anyway) or get it from a third party (ie an online lookup, which is what OCSP is). The forefront of CRL design is in set compression techniques like Ribbon filters https://…

I never said MHT are a solution for offline checks. That is a completely different problem space.

In the space domain, satellite ground systems have used a combination of guards, one way transmission, and others, although I am in favor of system-specific certificate whitelisting via running OCSP with local VAs, backed up by smart clients, with CRLs on the filesystem and in network shares.

CRL processing can cause timeouts, which is why it is always less preferred than the much more lightweight OCSP by comparison.

Furthermore, CRLs are blacklists, and newer OCSP is not exclusively, and, OCSP permits more flexibility with the various trust models that exist for it.

Re: A New Life for Certificate Revocation Lists

#69

Post by OrvalWintermute »

aaomidi wrote: post #66
mholt wrote: post #52

Earlier quoted context omitted.

It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems). OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.* * Thi…

A few hundred bytes is a ton data for something that a lot of people don’t particularly care about, and is still broken despite OCSP stapling. People don’t have low latency, clean internet all over the world and adding something like this on top of an already pretty bloated negotiation doesn’t help. As for the alternative not a single browser out there validates OCSP out of the box on the hot path (e.g actually waits…

This is a brower problem, but it is configurable.

Re: A New Life for Certificate Revocation Lists

#70

Post by OrvalWintermute »

Thorrez wrote: post #62
OrvalWintermute wrote: post #61

Earlier quoted context omitted.

No. That isn't the same. CRLs and OCSP are about individual certificates. The beauty of Merkle Hash Trees for validation is it permits Statements e.g. CAx = CA2 and 156 ≤ X The statement cj indicates that the certificate with serial number X = 156 issued by CA2 has been revoked, while the certificates with serial numbers from X = 157 to X = 343 (both included) issued by CA2 have not been revoked. From https://www.res…

Wouldn't a CRL that lists all the revoked certificates tell you that exact same information?

CRL's format is to list all the serial numbers in a blacklist, which means a CRL for a large well-used PKI is going to be gigantic by comparison to an MHT.

A CRL is not equivalent to modern OCSP, because modern OCSP can operate as a whitelist or a blacklist. However, CRLs are generally more secure than some of the OCSP variants because strong OCSP is used less (Nonced+authenticated/registered), and CRLs are not subject to replay attack like vanilla OCSP can be.

Post reply on HN