vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

ch4: flooding

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-28 19:10:26 +01:00
parent ff50c50460
commit be36e09fd0
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 13 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

25
book/source/04-certificates.md
View file

@ -544,11 +544,7 @@ Different mechanisms allow certificate lookup by email, for example:
- The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs)
- Traditional-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software)
Their properties differ:
- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance.
- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components.
- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]).
Their properties differ, also see {ref}`distribution`.
[^hip1]: <https://github.com/hockeypuck/hockeypuck/issues/136>
@ -578,7 +574,7 @@ Third-party certifications can be published as part of the target certificate to
So, there is some tension between the goals of
- a decentralized system where every participant can access certification information and perform analysis on it locally,
- privacy related goals (also [see above](email-lookup), in the comparison of email-based certificate lookup mechanisms, which also touches on this theme).
- privacy related goals (also see {ref}`email-lookup`, for a comparison of certificate distribution mechanisms, which also touches on this theme).
(unbound_user_ids)=
### Adding unbound, local, User IDs to a certificate
@ -590,9 +586,20 @@ Some OpenPGP subsystems may add User IDs to a certificate, which are not bound t
Sequoia additionally certifies these "local, third party, User IDs" with a local trust root to facilitate local authentication decisions.
To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable.
(distribution)=
### Certificate distribution mechanisms
Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space:
- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance.
- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components.
- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]).
(cert-flooding)=
### Third-party certification flooding
Traditional OpenPGP keyservers are one mechanism for [collection and distribution](distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications.
While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks.
Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users.
@ -600,9 +607,3 @@ Without any restrictions in place, malicious entities can flood a certificate wi
It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation.
The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019.
TODO: merge in text from ch8:
```text
However, in systems that unconditionally accept these certifications, it can lead to unintended consequences. Specifically, this approach has been exploited to cause denial-of-service attacks through [certificate flooding](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), a problem notably experienced by the SKS network of OpenPGP servers.
```