What To Use Instead of PGP

It's been more than five years since The PGP Problem was published, and I still hear from people who believe that using PGP (whether GnuPG or another OpenPGP implementation) is a thing they should be doing. It isn't. The part of the free and open source software community that thinks PGP is just dandy are the same kind of people that happily use…

http://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

What To Use Instead of PGP - Dhole Moments

It’s been more than five years since The PGP Problem was published, and I still hear from people who believe that using PGP (whether GnuPG or another OpenPGP implementation) is a thing they s…

Dhole Moments
@soatok nobody thinks openpgp is great. But the proposed alternatives aren’t replacing openpgp because they are not solving the big problem - identity and keys. Producing a modern signature is the trivial part. Solving only that part doesn’t solve real world problems (or deployments)
@letoams I dunno, the post kind of addresses that.
@letoams @soatok Hmm, perhaps we could map SSH keys identity to people very similar way as OPENPGPKEY record in #DANE, but with #SSHFP instead. We could reuse the algorithm for owner name creation, just use different record. But does not match how I use my SSH keys. I have each per machine, not one per person. I think I do them how I should, right?
GitHub - fedi-e2ee/public-key-directory-specification: Specification for a Fediverse Directory Server for Public Keys

Specification for a Fediverse Directory Server for Public Keys - fedi-e2ee/public-key-directory-specification

GitHub
@soatok @letoams How does the Fedi server authenticate itself? Can we perhaps use DNSSEC for that too? I admit github.com and gitlab.com could already identify myself with my SSH keys identities and attest for others, these are my keys.
@pemensik @letoams We do not need DNSSEC for this.
@soatok @letoams But it would not hurt having the possibility to use it for it, right? Because unlike certificate revocations, short lived DNS caching scales better with higher usage, IMO?
Against DNSSEC — Quarrelsome

@pemensik @letoams The system I'm designing is meant to be a standalone building block for other protocols.

The question of "how do we validate it?" can be interpreted multiple ways, and therefore has multiple answers.

  • It's an append-only ledger, via Merkle trees.
  • The Checkpoint message between PKD instances.
  • Replication (mirroring).
  • Witness co-signatures (Sigsum).
  • The question of "which PKD is used?" can be addressed by clients (if they have preferences) or Fedi instances (the usual case).

    Trusting or distrusting a PKD is a social problem, not a technological one.

    @pemensik @letoams I view DNSSEC as a solution looking for a problem.

    If someone wants to shove something into another layer (DNSSEC, Ethereum smart contracts, whatever), you're free to do so, but it will NOT be part of my design and I will not be dragged into discussions about them.

    @soatok @letoams Sure, nobody forces you. Though Merkle trees complicates whole design a lot IMO, DNSSEC allows much simpler verification from a single trusted root key. More straightforward design, just top-to bottom verifiable chain. But our crypto team has similar relationship of DNSSEC as you do.
    @pemensik @letoams I think we're done here.
    @soatok @letoams I were targetting Paul anyway, left you there just because it was preselected. Thanks for your post anyway. Was useful and loved those Art cards in a tech article. Makes it more memorable.
    @soatok @letoams For example mastodns.net is a Fedi server on #DNSSEC signed zone, algorithms 13 or 8 used only. I see no weakness if they would allow publishing of keys, RFC 7929 style. But with #SSHFP RR digests, to prove my identity of git ssh signed software, just like you have proposed. Just choose well your TLD and that's it. Append only log is important to prove no other CA made cert for my name. But we have just one parent domain key in #DNS. Give it a chance, it is not so bad. 😀
    @letoams Similarly may publish #SSHFP record of #gitlab users. Both gitlab.isc.org and gitlab.nic.cz are on DNSSEC signed domains. Gitlab knows SSH keys of their users, very often used. They could export them for outer verification, just some way of mapping SSH key to username is required. We have that concepts for OPENPGPKEY and SMIMEA records. Would a new draft for SSHFP make sense too? Should it include public key directly in DNSKEY/KEY record?
    @soatok @letoams I cannot agree with that post, that is just DANE hate. Yes, you need to choose domain where you provide your services. You have to even with domain validated X.509 certs. Otherwise, I am DNSSEC supporter, quite against Don’t support it. statement.

    @soatok @pemensik @letoams That 10+ year-old blog post and other page from the author have been widely cited in critiques of DNSSEC. While there may be much to criticize and dislike, the underlying message is probably weaker than you might imagine. Or at least, there have been a lot of reasonable criticisms of those criticisms.

    Implementation and deployment experience of the challenges, strengths, weaknesses, and risks are usually more nuanced than what appears in most blog posts

    @jtk @pemensik @letoams I don't know how many times I have to express this for it to sink in but

    I DO NOT CARE ABOUT DNSSEC

    @jtk @soatok @letoams I agree. Compared to other well-reasoned and explained problems in original PGP article, this is just very shallow and often bogus or misleading. The biggest problem of DNSSEC are broken middle boxes IMO, which with rise of DoT will become less and less significant. And of course requires correct deployment and maintenance, which requires extra knowledge and resources.
    @soatok @pemensik thomas’ sock puppet article that refused to correct itself after I pointed out many failures in it doesn’t need more quoting at me, thank you. See twitter flame wars 🤣
    @letoams @pemensik As I said elsewhere, I am deeply uninterested in DNSSEC discussions
    @soatok @pemensik I will have to read up on that. Good to see some kind of specification at least. Not sure why merkle trees yet. Not sure about binding properties (eg if my server admin takes over my account).
    But also, you need a generic identity + pub key. Email is unique because if user@fqdn but most people don’t own their fqdn. Unique identities are hard, email is sadly still the most universal
    @letoams I were referring to use SSH Key to sign git code, described at https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html. As you pointed, email like IDs are missing. It could generate [email protected] with SSHFP records of my keys exported. Meaning user at hostname. The same on fediverse server, even on Fedoraproject.org. SSHFP are short, unlike full keys. You could have also full pubkey in DNSKEY format, but FP is enough, if you have pubkey already.
    Sign commits with SSH keys | GitLab

    Sign commits in your GitLab repository with SSH keys.

    @letoams as you pointed out, not everyone has own domain. This could be operated by a service, where the user has just a reasonably protected account with SSH pub keys included.
    @pemensik I don’t see my ssh key as my signing key. Especially with the outdated ssh -A, it puts my key on too many servers for me to trust it for signing git commits
    @letoams Okay. You could use different key for signing or mark the key not forwardable, but fair enough. Still mapping an username to public SSH key would be great for a simple allowing username to SSH into some machine. You could generate .ssh/authorized_keys from simple [email protected] address, if SSH pubkey were in the DNS.
    @letoams @soatok Except both ssh-keygen and ssh-keyscan print SSHFP *also* in SHA1. I have to suppress it explicitly by -O hashalg=sha256. Not secure then?