REOPEN: #2210 Offer GPG signature(s) and checksum(s) of public_suffix_list.dat

[nf-brentsaner]

Reopening #2210 , as it was closed while completely ignoring the root of the request.
So let me be more explicit:

• Sign the list. There is no way to verify the integrity of it.

• [FEATURE/SECURITY] Offer GPG signature(s) and checksum(s) of public_suffix_list.dat #2210 was closed with "The website is already the only authoritative source of the list. This is explained at the top of the list. Signing with keys which are published on the same site would accomplish very little." This is a CLEAR DEMONSTRATION the original text was not read:

Publish a list of valid key/keys' full fingerprints on multiple channels ... on publicsuffix.org ... and the key(s)/fingerprint(s) included somewhere within this (publicsuffix/list) repository

There are two places listed, and for good reason: the former is for convenience/authoritative, the latter is for out-of-band agreement in the event the former is compromised or vice versa.

This was an incredibly lazy, unprofessional, and dismissive response for a perfectly valid, reasonable, and required request.

Re-evaluate the original request, as reproduced below:

In order to verify integrity against (what seems like an increasing number of) supply-chain attacks, it would be beneficial to this project to cryptographically sign and hash files intended for remote use.

There are currently no protections in place, aside from HSTS'd HTTPS (of which requires a visit to the site at least once before, assuming one is even using a caching client), to ensure that the *content* of the list has not been corrupted in-transit or maliciously altered.

Personal recommendations:

* Publish a list of valid key/keys' full fingerprints on multiple channels, optionally with the ASCII-armored public key/keyring itself
  * This can be satisfied by publishing static versions of the fingerprint/key on `publicsuffix.org` that is *not* pulled from https://github.com/publicsuffix/publicsuffix.org (as the site itself is hosted via Google), *and* the key(s)/fingerprint(s) included somewhere within this (`publicsuffix/list`) repository (thus requiring two separate compromises to replace the key with an attacker's instead of only one)
* Have a vetting process for valid signers and keys
  * Signatures should not be made from DSA keys, or RSA keys <2048 bits
* Allow multiple signers to sign
* Sign the `public_suffix_list.dat` file using ASCII-armored detached signatures of at *least* SHA512 (if not a SHA3 algorithm) checksumming.

[simon-friedberger]

I am sorry my response offended you, that was not my intention!

Could you please explain your use-case so we can have a more focused discussion? Maybe elaborate on why you think HTTPS is not sufficient protection for the PSL in comparison to, for example, downloading the actual browser which is using it.

[nf-brentsaner]

Having a single authoritative source on a single provider requires that only the credentials to any account(s) with edit access to that website's management be compromised (which is not that outlandish to imagine).

Checksums alone are useful for download integrity or for caching purposes; they provide a quick method of checking that content has been changed or not. (Granted, ETag/RFC 7232 does essentially the same for this purpose, but etag verification/caching isn't supported as commonly as, say, SHA-2 or SHA-3 checksums.)

But these do not provide authorization integrity, which is what the signing is for. This provides attestation by one (or more) parties that guarantees the content of the data is valid. This prevents plenty of mishaps (HTTPS proxies - common in corporate environments, expired certificates, CA compromise, the above-referred website compromise, et. al.) from successfully corrupting consumers of the list provided.

Example

Scenario 1

A malicious actor (perhaps criminal-organization-sponsored; given that this list is definitely used by Debian's bind install, for instance, it's a high-value target) wishes to add validation for a suffix that should not be normally propagated.
They successfully execute a spear-phishing campaign (or other attack) against an individual with direct commit access (e.g. one of members or a common committer with a high level of trust).

They then add their target suffix to the list, or add injection of it into one of the actions, etc. in such a way that it raises minimum alarms.
This suffix is then published in the list.

Scenario 2

Alternatively, the same actor may gain access to one of the Google Sites accounts with management access to publicsuffix.org.

They can define their own data source for the List that deviates from this repository, replaces it on a random schedule, replaces it based on client IP range, etc.

Their suffix is then published in the list.

How Signatures Mitigate This

By specifying "authorized" key ID(s) (ideally multiple), and publishing these authorized key IDs in both a static definition on Google Sites and in this repository, this would require compromising both a GitHub account and a Google Sites account with appropriate access to change those key IDs. This significantly raises the cost of the attack.

By requiring signatures for these key IDs (for example, 3 keys -- 1 key each across 3 individuals) to sign the list for it to be considered "valid", consumers of the List may validate against the key ID list above. This would require compromise of all three individuals' local machines to successfully validate a malicious entry instead of only compromising a single credential in either Google or GitHub.

This additionally provides consumers with the ability to cryptographically validate the integrity of the List directly instead of relying on any sort of invisible attestation (e.g. "But I use 2FA").

[simon-friedberger]

There are indeed attacks which can be prevented by having additional signatures and verifying them. There is no disagreement on the general methods involved.

I think the main issue here is that the trade-offs are wrong. Is there a use-case that makes the PSL such a high-value target that it would be appropriate to add these signatures?

[dnsguru]

There are some maintainer / volunteers that have a perspective on the PSL that narrowly focuses on browser use and needs, with other purposes being irrelevant.

While browser-purposed use was the genesis of the PSL, usage expanded beyond the browsers' purposes because the PSL is the least shitty, most frequently maintained resource of its kind for adding elegance to domain handling.

The issue identifies another crucial use case that we might benefit from documenting.

We also should note more clearly in the documentation and disclaim that there should absolutely never be use cases that infer ANY security from this catalog, and dissuade any use that presumes ANY security inferrence from it.

[simon-friedberger]

The issue identifies another crucial use case that we might benefit from documenting.

That is precisely the problem here, we have no information about the use-case or about who is going to verify these signatures.

@dnsguru I am not entirely sure if you were being sarcastic or serious here but if you want to start providing signatures for the list contents we can certainly do that.

[mozfreddyb]

@simon-friedberger I feel like I am reading the comment from Jothan differently from you.

I think it's great to acknowledge that there is a responsibility to make the PSL work for existing use cases and get a better understanding of those. But the responsibility goes in both direction. The maintainers of bind (or the Debian package) should not include dependency updates without any kind of review either.

Anyway, +1 to documenting that bind (or the Debian package) appears to make us of this.

[dnsguru]

@dnsguru I am not entirely sure if you were being sarcastic or serious here but if you want to start providing signatures for the list contents we can certainly do that.

I don't think adding signatures like this is of significant benefit. I was suggesting we add this additional use case beyond those known.

"Juice to squeeze ratio" on sigs is low, and it seems like it is going to introduce yet more burden on PSL to benefit yet another thord party project that is better resourced.

I appreciate the request and their objective, but if a distro opts to do something like this, IMHO that distro can do the shim work to host their own high integrity PSL dat mirrror.

[simon-friedberger]

I am not particularly competent with Debian package internals.

I did some digging and all I could find are recursive dependencies via

• curl & wget: cookies
• libsoup: a HTTP library, so probably also cookies
• network-manager: To check if a domain is valid. Afaiu, they are using that to select the search domain for unqualified lookups based on the hostname.

@nf-brentsaner could you help me out with what bind9 is using the PSL for?