To be pedantic for a moment, ARIN etc. are registries.

The registrar is your ISP, cloud provider etc.

You can get a PI (Provider Independent) allocation for yourself, usually with the assistance of a sponsoring registrar. Which is a nice compromise way of cutting out the middleman without becoming a registrar yourself.

VBA et al succeeded because they enabled workers to move forward on things they would otherwise be blocked on organizationally

Also - not seeing this kind of thing could be considered a gap in your vision. When outsiders accuse SV of living in a high-tech ivory tower, blind to the realities of more common folk, this is the kind of thing they refer to.

Erm ? Do I have to spell out that I was pointing out that there was more than the "ephemeral services" that were being guessed at that could take advantage of IP certs ?

Why? Even regular certs are handed out via IP address.

It depends. If the ACME client is configured to only use Let’s Encrypt, then the answer is yes. But the client could fall-back to Google’s CA, ZeroSSL, etc. And then there is no single point of failure.

But in general, one of the points of ACME is to eliminate dependence on a single provider, and prevent vendor lock-in. ACME clients should ideally support multiple ACME CAs.

For example, Caddy defaults to both LE and ZeroSSL. Users can additionally configure other CAs like Google Trust Services.

This document discusses several failure modes to consider: https://github.com/https-dev/docs/blob/master/acme-ops.md#if...

TLS certs should be treated much more akin to SSH host keys in the known hosts file. Browsers should record the cert the first time they see it and then warn me if it changes before it's expiration date, or some time near the expiration date.

Probably not. For browsers to accept this certificate it has to be logged in a certificate transparency log for anyone to see, and no such certificates have been seen to be logged.

This makes sense from a security perspective, insofar as you agree with the baseline position that revocations should always be honored in a timely manner.

Nobody is being forced to use 6-day certs for domains though, when the time comes Let's Encrypt will default to 47 days just like everyone else.

(The classic problem with self-signed certs being that TOFU doesn’t scale to millions of users, particularly ones who don’t know what a certificate fingerprint is or what it means when it changes.)

Hardly 'by definition niche' IMHO.

So no one that actually has to renew these certificates.

Hey! How long does a root certificate from a certificate authority last?

10 to 25 years?

Why don't those last 120 minutes? They're responsible for the "security" of the whole internet aren't they?

Otoh, if you're dealing with browsers, they really like WebPKI certs, and if you're directing load to specific servers in real time, why add DNS and/or a load balancer thing in the middle?

ie. https://10.0.0.1(af81afa8394fd7aa)/index.htm

The identifier would be generated by the certificate authority upon your first request for a certificate, and every time you renew you get to keep the same one.

1. Running a CA is more work than just setting up certbot for IP addresses, but not that much more

And that enables you to

2. Remember only domain names, which is easier than ip addresses.

I guess if you're ipv4 only and small it's not much benefit but if you have a big or bridged network like wonderLAN or the promised LAN it's much better.

I don't think the root programs take these kind of decisions lightly and I don't see any selfish motives they could have. They need to find a balance between not overcomplicating things for site operators and CAs (they must stay reliable) while also keeping end users secure.

A lot of CAs and site operators would love if nothing ever changed: don't disallow insecure signature/hash algorithms, 5+ year valid certs, renewals done manually, no CT, no MPIC, etc. So someone else needs to push for these improvements.

The changes the root programs push for aren't unreasonable, so I'm not really concerned about the power they have over CAs.

That doesn't mean the changes aren't painful in the short term. For example, the move to 45 day certificates is going to cause some downtime, but of course the root programs/browsers don't benefit from that. They're still doing this because they believe that in the long term it's going to make WebPKI more robust.

There's also the CA/Browser Forum where rule changes are discussed and voted on. I'm not sure how root programs decide on what to make part of their root policy vs. what to try to get voted into the baseline requirements. Perhaps in this case Chrome felt that too many CAs would vote against for self-interested reasons, but that's speculation.

ECH needs for the outer (unencrypted) SNI to be somewhat plausible as a destination. For ECH GREASE what happens is that this outer SNI was real, what looks like the encrypted inner ECH data is just random noise.

For non-GREASE ECH we want to look as much like the GREASE as we can, except that it's not noise that's the encrypted payload with a real inner SNI among other things.

This is fact, not FUD.

Microsoft has had multiple RCE vulns in their ipsec stack in the last two years.

The big vendors like Cisco had ipsec vulns for decades.

These days the issues are pretty well known and documented, but it really is a bad standard.

That's pretty reasonable, considering it is built in to all the major code signing tools on Windows, they perform the identity verification, and the private keys are fully managed by Azure. Code signing certs are required to be on HSMs, so you're most likely going to be paying some cloud CA anyway.

Consider secure boot; assuming it's properly implemented, could defend against an entire class of attacks—evil maid: if a third party physically compromises your machine while you're away to install malware, you'd be alerted or stopped from booting the modified image. This is a technical statement. Now whose keys are actually trusted to sign these images? The answer is whatever power dominates in the supply chain: Microsoft, on desktop devices, and the vendor on mobile.

In the case of Microsoft, the public indignation eventually forced them to open this system up, letting the poweruser delegate their agent freely and without manufacturer's coercion. But what about Android, where the natural market forces did get the upper hand: most phones remain locked from disabling secure boot, even fewer let you enroll your own keys. They result is that most Android phones cease security updates only a few years after manufacture, the vendor's own software riddled with obvious faults (like filling a user-inaccessible partition with logs that never get wiped, even after factory reset) and known CVEs, yet nevertheless remain attested as secure for high-assurance applications like banking, as determined by Google. This hypocrisy isn't accidental: the system's real aim was not to secure the user, but to secure its monopoly, instrumented by privileged Google Play Services, harvesting data beyond what any SDK can.

I myself regularly rely on attestation—my phone runs Graphene OS and my laptop self-signs its kernel for secure boot—but I recognize that these technologies in themselves are predisposed to misuse by anti-competitive corporations and repressive regimes.

Imagine government ID backed app signing became the norm for app stores. There will no longer be open-source utilities, like scientific calculators, notes, and budget planners, as they would not bear the certification fee what is effectively volunteer work, instead replaced by their ad-ridden copycats mass-produced in a software sweatshop, featured alongside or, through malicious ads, directing to assorted malware, still just as prominent as before, signed using passport details of random people off the street, taken down as late as they can, because Google enjoys a steady revenue stream from their repeated publisher verifications and AdSense spots. And that's to say nothing of censorship circumvention tools and other politically inexpedient software.

Currently ACME sets its cron job to 12 days on 90 day certificates.

Fuzzing the lifetime of certificates would smooth out traffic, encourage no hardcoded values, and most importantly statistical analysis from CT logs could add confidence that these validity windows are not carefully selected to further a cryptographic or practical attack.

A https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number if you will.

> A regular 160-gon is constructible with straightedge and compass.

> 160 has a representation as a sum of 2 squares: 160 = 4^2 + 12^2

> 160 is an even number.

> 160 has the representation 160 = 2^7 + 32.

> 160 divides 31^2 - 1.

> 160 = aa_15 repeats a single digit in base 15.

[1] https://www.wolframalpha.com/input?i=160