It is hard enough for people to keep up with one keychain, let alone a dozen of them for every use case in their lives.
PGP keychains allow you to have a single 24 word mnemonic seed to recover your entire digital identity, data access, etc. The UX is strictly better than the commonly suggested hodge podge of flavor of the week alternatives.
I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incompatible with the IETF's standards. It's not clear why.
From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary.
Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard.
So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.
It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters. FWIW, here is the LibrePGP proposal:
Observing the OpenPGP schism mess I think I have gained some insight as to why some RFCs become so bloated. For example it has been recently pointed out that there are 60 RFCs for TLS (with 31 drafts in progress)[1]. The RFC process seems to be more optimal during the design phase. Once we have an established standard there should to be some way to force those that propose changes/extensions to provide appropriately strong justifications for those changes/extensions. Right now it is a popularity contest and there will always be more people out there in favour of changes/extensions than those willing to endlessly fight against those changes/extensions. Because cryptography is so specialized and obscure, the users tend to get left out of the discussion.
And anyone can put forward a draft. Here's one for "IPv8" with increased security where "manageable element in an IPv8 network is authorised via OAuth2 JWT tokens"
> It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters.
I don't think this is really true. A huge fraction of proposed documents just go nowhere, and it's really quite common to see a new proposal get presented and be shot down by one or two people (Source: I've been one of the people doing the shooting down on more than one occasion)
It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.
- As a practical matter, anything that is a Proposed Standard RFC is a standard. In principle, there is a two-level system with PS and Internet Standard (down from three levels) but most WGs don't bother to advance specifications past PS. For example, TLS and QUIC are both PS.
- RFC 9580 obsoletes RFC 4880, so from the perspective of the IETF, it supersedes it. Of course, this doesn't make people do anything.
As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written.
it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along.
my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.)
LibrePGP is also a rewrite. To keep supporting legacy v4 you have to keep having v4 code no matter if the new thing you add is v5 (LibrePGP) or V6 (the RFC)
actually neither are complete rewrites. i played around with diff and found that the new version of OpenPGP seems to keep about 60% of the old one and LibrePGP seems to keep 90%.
so the rewrite claim was exaggerated. i didn't compare the stuff that was added or merged.
The claim is even more exaggerated than that, because a lot of the diffs between 4880 and 9580 are editorial and structural, and don't have any semantic effect.
> the new standard is a complete rewrite of the old one. they are not even compatible anymore.
My honest first reaction to this statement would get me permabanned from this site, so here’s the polite version:
This is nonsense on stilts. It is so ill-informed and baseless I struggle to understand how anyone who has read the RFCs in question could possibly come to this conclusion. It is hooey.
> things the old standard used to support are not supported in the new standard.
Aside from deprecating some ancient cryptographic algorithms that nobody uses any more, everything from RFC4880 is in RFC9580. Can you point out a concrete example of something (non-obsolete!) that is missing?
> that makes any implementation of the new standard incompatible with implementations of the old one.
That is news to every openpgp implementation other than gnupg, which have happily implemented both. Even RNP have it in a feature branch somewhere.
> (source: i talked to a GnuPG developer)
Which one? When? It would genuinely help if they would go on the record. I strongly suspect their actual opinion would differ from what you’ve reported here. There’s enough hearsay nonsense about the schism floating around the internet as it is, without adding to it.
i appreciate you making the effort to register an account to make this comment. i have addressed some of the issues raised in a comment here: https://news.ycombinator.com/item?id=48058065
i hope you'll notice this reply and get a chance to read it.
The situation is farcical, and stems from the double bind that PGP has been in for at least 20 years: the standards are bad and need modernization, but it’s impossible to modernize them because the single thing that retains “serious” users of PGP is backwards compatibility.
The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.
PGP covers the case where data is encrypted and might stick around in that state for a long time. Decades. So backwards compatibility is essential.
Fortunately we can use the existing standard (RFC-4880) in a way that is completely secure. Remember, we are talking about the standard that was in effect when the Snowden leak revealed that PGP is on a very short list of things the NSA has no access to. There is no reason to think that has changed since then.
I’m sorry, but it’s beyond the domain of serious discourse to assert that RFC 4880 is “completely secure.” This isn’t a position that even die-hard PGP fans take.
(As just one small example: the only mandatory symmetric cipher in 4880 is 3DES, and nobody serious is recommending 3DES for long term stored encryption in 2026.)
I stated that it was possible to use RFC-4880 in a way that is completely secure, not that every possible use is completely secure.
Your example mentions 3DES. 3DES is secure. The reason it is not recommended is because 128 bit block lengths allow longer file/message lengths than 3DES can accommodate on one key. At any rate, RFC-4880 permits the use of AES and that is what is normally used.
This is incongruous with your original argument: AES is optional, so anybody doing cold storage with PGP on messages they don’t fully control (again, the backwards compatibility story) is going to end up using 3DES.
And no, you can’t brush aside 3DES being insecure for large messages and then call it secure. Modern cryptographic tools don’t allow that, because there is (again) universal consensus that it’s insecure.
There are no preferences available for symmetrical encryption. GnuPG for example does AES for symmetrical encryption by default. Is it violating RFC-4880? I think things get philosophical here.
I doubt that there is an implementation left that does 3DES by default.
It would be nice to update the standard to make AES required to be available for decryption. I really wish that the most recent standard update attempt had restricted their scope to such uncontroversial changes before going to war over the controversial changes.
That’s still incongruous with your original argument: using AES for long term encryption isn’t (particularly) controversial, but using it via a scheme that only mandates 3DES absolutely is. The default is immaterial in the setting being discussed, since for compatibility you don’t get to control how the data was originally encrypted.
Edit: I say “particularly” because I don’t think any cryptographer would endorse 4880’s only mode of operation for AES.
> The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.
Unfortunately there's something akin to a conflict of interest with both RNP and OpenPGP. OpenPGP guys have gpgsm, and RNP people also maintain the S/MIME part in Thunderbird. Both have stagnated and are holding back what would have otherwise moved on.
Short version: Werner Koch personally hates some people involved with the RFC9580 standardization, and cannot emotionally bear working with anything even loosely associated. He also struggled accepting anyone's opinion but his own while editor of the draft back then.
Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).
GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
On the other side of the coin, they also punish people who have slow connections. The acceptable speed for downloading from github on my connection is 90k/sec. No more, no less. Something prevents the rate from being higher (probably Github), and if the rate drops any lower for any length of time, the connection will suddenly abort right in the middle of the download. Since the dumpster fire that is git doesn't support resume, welcome to hell. If I didn't have a fast server elsewhere to git to then zip up and re-download, I'd be screwed.
My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.
The very same thing happen on my residential connection, I can do one search query, then I'm rate limited for 15+ minutes, same if I access any list of commits.
I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.
Hm, I've also noticed sites being more aggressive about verifications after I started using LLMs locally. They think I'm a bot (which... fair), even on completely unrelated sites I seem to be getting prompted for human verification much more often.
No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
> No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.
No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.
ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.
> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.
It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.
What can you do to get a new IPv6 network that is easier than getting a new IPv4?
Stuff like bouncing a modem, getting a new VPS, making a VPN connection I would expect to be pretty similar. And getting a block officially allocated to you is a lot of work.
Why are we pretending that you are checking logs and adding firewall rules manually. Anything worth ddosing is going to have automatic systems that take care of this. If not put an ai agent on it.
IPv1, IPv2, and IPv3 were very early experimental versions of the Internet Protocol developed in the 1970s during the ARPANET era (the precursor to the modern internet). Has anyone tried to find out if GitHub is reliable on those?
Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.
twinax I think is used more like a balanced line with shielding. Twisted pair is preferred because it is cheaper, but for short stuff like SATA the cost difference is so low it might as well be used
I remember removing the IPX route entries from our Cat65 MSFC back in 2006 and from the ATM/Framerelay WAN Equipment. Wasn't very popular with the customers.
I also remember the first IPv6 Workshop on W2k SP3 back in 2002. Not that long ago.
I do similar, but frame it in terms of dependencies.
The database can live without the web server, but the web server doesn't work without the database.
Therefore webserver ---> database.
Key thing in that these deployment / context / container diagrams don't have a temporal axis. If you want to represent a flow, then you want a diagram where time has directionality, like a sequence diagram.
If I accidentally yank the power cable out of my load balancer, I can plug it back in and I'm back up and running.
If I cock up my DNSSEC config, nobody can resolve any records under my org's domain (goodbye internal email!) and you've got to twiddle your thumbs for a period of time waiting for various timeouts to pass (go ask Slack how it went for them).
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol.
With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party.
I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
Thanks for the explanation. It seems like there are two cases here:
1. Things that use TLS and hence the WebPKI
2. Other things.
None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
> None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.
> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
But do they? That requires adding support for another protocol.
I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.
In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security.
There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.
And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me!
DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.
Don't get me started on how badly VPN PKI is handled....
Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations.
The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI.
The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
No, we run a fleet with thousands of physicals and hundreds of thousands of virtuals, of course we don't hardcode keys in our SSH configuration. Like presumably every other large fleet operator, we solve this problem with an internal SSH CA.
Further, I haven't "moved on to another argument". Can you answer the question I just asked? If I have an existing internal PKI for my fleet, what security value is a trust relationship with DNSSEC adding? Please try to be specific, because I'm having trouble coming up with any value at all.
We also have thousands of devices accessible over SSH and we maintain our own PKI for this purpose as well. We also use mTLS with a private CA and chain of trust, for what it's worth.
That entire post is that you should enable DNSSEC because it's "more secure", and there are no reasons not to.
"More secure" begs the question "against what?", which the blog post doesn't seem to want to go into. Maybe it's secure from hidden tigers.
My favourite DNSSEC "lolwut" is about how people argue that it's something "NIST recommends", whilst at the same time the most recent major DNSSEC outage was......... time.nist.gov! (https://ianix.com/pub/dnssec-outages.html)
If you're in (for example) a CI context and do a git checkout @tag, there's no guarantee that you'll get the same content as the last time you fetched that tag.
Where is this mythical social contract found? I stand by my point: it's a software license, not a marriage.
Free users certainly would like it to be a social contract like I would like to be gifted a million dollars. Sadly, I still have to work and can't infinitely rely on the generosity of others.
Your analogy doesn't make sense. You are getting benefits from using the shopping cart and you bring back as it's expected as part of the exchange. You bring the cart back to where you took which is a low effort commitment entirely proportional to what you got from it.
Free software developers are gifting you something. Expecting indefinite free work is not mutual respect. That's entitlement.
The common is still there. You have the code. Open source is not a perpetual service agreement. It is not indentured servitude to the community.
Stop trying to guilt trip people into giving you free work.
MinIO accepted contributions from people outside the company who did work on it for free, usually because they expected that minio would keep the software open source.
I always preferred people who didn’t, when I worked in retail. It generates a nice chill task (wander around the parking lot looking for carts). But if you want to do a favor for the faceless retailer, go for it. Mostly I chuck my cart in the corral to get it out of my way, but this sees more like a morally-neutral action to me.
In this context the social contract would be an expectation that specifically software developers must return the shopping cart for you, but you would never expect the same from cashiers, construction workers, etc.
If the software developer doesn't return your cart, he betrayed the social contract.
Maybe this is the case, but why is your presumption of entitlement to free labor of others the assumed social contract, the assumed "moral" position, rather than the immoral one?
Why is the assumed social contract that is unwritten not that you can have the free labor we've released to you so far, but we owe you nothing in the future?
There's too much assumption of the premise that "moral" and "social contract" are terms that make the entitled demands of free-loaders the good guys in this debate. Maybe the better "morality" is the selfless workers giving away the product of their labor for free are the actual good guys.
That's not what a social contract is you are thinking of a legal contract, something very different. A social contract is by definition, implicit rather than explicit.
It was not expectation when they started, did a lot to lure many into the ecosystem. When you release it free, wait for the momentum to build, then you cut off, it is something else. And the worse is they did it in a very short time. Check out elasticsearch, the same route but did not abandon the 7 release like this.
I know all about ElasticSearch, MongoDB, Redis, etc. Yes, what they did sucks. No, it doesn't make the maintainers bad or anything. It's still on the user to know that anything can happen to that spiffy project they've been using for a while, and so be prepared to migrate at any time.
Expectations are maybe fine maybe not, but it's funny that people can slap the word moral onto their expectation of others being obligated to do free work for them, and it's supposed to make them be the good guys here.
Why do you presume to think your definition of morals is shared by everyone? Why is entitlement to others labor the moral position, instead of the immoral position?
This is technically true, and nobody contested the CABF's focus on HTTPS TLS.
However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.
I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.
> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.
The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.
There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.
> The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser and other relying‐party software applications.
IMHO "other relying-party software applications" can include XMPP servers (also perhaps SMTP, IMAP, FTPS, NNTP, etc).
It is a single member of the CAB that is insisting on changing the MAY to a MUST NOT for clientAuth. Why does that single member, Google-Chrome, get to dictate this?
Has Mozilla insisted on changing the meaning of §1.3 to basically remove "other relying‐party software applications"? Apple-Safari? Or any other of the "Certificate Consumers":
The membership of CAB collectively agree to the requirements/restrictions they places on themselves, and those requirements (a) state both browser and non-browser use cases, and (b) explicitly allow clientAuth usage as a MAY; see §7.1.2.10.6, §7.1.2.7.10:
Which bit of PGP?