kensey

Anything that doesn't eliminate the current model of "a whole pile of CAs of unknown and widely-varying reliability are ultimately-trusted by every TLS client in the world despite the numerous times that has caused serious problems for approximately everyone on the Internet" is IMHO not significantly better than what we have now. The trust is the problem, and shorter certificate lifetimes or restrictions on usage flags or the various other things trying to work around that issue don't solve it no matter how many of them are implemented -- they're bandaids on a shotgun wound.

But let's whiteboard for a bit: if you agree (as I assume you do) that the current situation is at least more insecure than it should be, and should ideally change fundamentally, and if you don't think DANE is the right fundamental change, what would you implement instead if you had the magic wand to make everyone agree to do it?

Not lose control exactly. But if ICANN is willing to, they have the power to simply make that control irrelevant in any specific case. The government in question would have absolute control of a TLD registry that no one else considers authoritative for that TLD. If you're a hermit kingdom like North Korea anyway, that's probably not a big deal, but for anybody else it's liable to be a very big deal indeed.

I would expect ICANN to use that power very sparingly, preferring to publicize rather than act as a first step, and if they did get heavy-handed, again they would incur a hit to their legitimacy.

The only reason it's considered unthinkable that could happen to .com is that everybody agrees it's unthinkable to do that to .com. But ICANN absolutely could make a credible threat to US control of .com or .us if they felt it warranted to do so. (You could say they're ICANN, not ICANN'T.) They could do the same to .gov, for that matter, but the US government already explicitly owns and controls that whole hierarchy, so there's no real "interference" issue there.

The whole Internet's viability is based to some extent on the collective delusion that everybody agreeing this is how it works, actually makes it how it works. But none of that is set in stone... which is generally a good thing.

Honestly even if they were issuing certificates for much longer than they were supposed to, that is a way lower level of risk than "everybody in the world absolute-trusted a CA certificate that turned out to have a 256-bit private key crackable in seconds".

I'm not sure (but would love to know) if Sectigo actively chose to sign eMudhra's certs (though if eMudhra is a reseller of theirs, it would make sense to do so), or if maybe it was just "their turn in the barrel" to be the designated cross-signer of a new CA's certs so the new CA could be a useful entity.

There's no reason clients couldn't, as far as I know (just like the various anti-spam measures where clients check for records that indicate what servers are allowed to send mail from a domain and consider it spam if those records don't match), but I also don't know of any clients that actually do. And a CAA record still doesn't actively prevent issuance of a certificate, which is really what would be needed.

There used to be a pinning scheme called HPKP, but the trouble with it is it's very easy to accidentally (or via malicious third-party action) end up in a situation where your web site becomes unreachable by people who've visited it previously because the key changed and the pin prevents their browser recognizing the new key as valid:

https://scotthelme.co.uk/im-giving-up-on-hpkp/

So the answer is just to use only the weaker option forever?

You don't think so? In a scenario where it becomes known the US government is actively subverting Verisign to tamper with DNSSEC integrity (or where Verisign just screwed up badly enough to make their continued stewardship untenable, and I think either case would become known, in pretty short order), I absolutely think ICANN would expatriate .com. If they didn't, they would lose legitimacy with everybody who isn't the US government. That leads to at best an international effort to replace ICANN and at worst the splintering of the DNS root. Nobody wants either of those scenarios -- the least-damaging thing for the Internet and for ICANN as an organization would indeed to be to take .com away and let say, the British run it for awhile. (Maybe you could get your .com domain registrations at Sainsbury's, in the aisle next to the anti-demon plant misters.)

Which is exactly the kind of scenario a lot of people hyperventilated about back when ICANN was formed, for reasons of varying validity, but in this case it would indeed be the least-worst option all around.

See my other comment above. A malicious TLD operator is not something everyone is just powerless to deal with.

I don't think (and wouldn't hope) this would be a flag-day thing where we stop using CA trust completely all at once and only use DANE afterward. DANE would become an option, disabled or secondary by default, that users could choose to use as a fallback if CA-based TLS validation fails. Eventually as adoption increased and the critical paths got cleaned up, DANE could become the default primary, with a fallback to CA trust if there's no valid response to a TLSA record request. Eventually as CA trust fell completely out of favor for most uses, it wouldn't be necessary for many clients to support it at all.

If ICANN decides you no longer operate the TLD, and takes your name servers out of the root server zones and replaces them with somebody else's... you don't run that TLD any more, sorry, go have a good cry and then see if maybe running a hot dog stand is more your speed. DNSSEC is one of the services ICANN considers critical enough to take away your TLD stewardship if you aren't providing that service properly.

Of course we wouldn't want ICANN to do that on a whim, or without having a new operator for the TLD ready to go, but there's already process defined for both planned and emergency transfers of operation of a TLD:

https://www.icann.org/en/contracted-parties/registry-operato...

It seems much less likely that even a well-funded state actor could silently subvert enough root servers, which exist in many countries, to significantly compromise DNSSEC before alarms were raised, than that CAs are actively compromised or are just bad at being CAs, resulting in a breach like this (which happens approximately all the time). And with regard to state coercion, some CAs are in fact state-run, by states most people would consider grievously corrupt.

More to the point I would trust IANA and ICANN, faults and all, to not screw up the DNS/DNSSEC root, much more than I trust every CA in the default browser trust stores to get X.509 right all day, every day.

The big takeaway here is: Web PKI is fundamentally broken, and the existence of CAs as a concept is the vulnerability that must be fixed -- or, more specifically, the idea that ultimately trusting a relatively small, basically fixed/hard-to-change set of (mostly) commercial entities with something this critical and far-reaching is (or ever was) actually a good idea.

There are a lot of reassuring statements from browser makers and others about how their mitigations for exactly this scenario kicked in and protected (some set of) Internet users, but IMHO there is not nearly enough discussion happening about fixing things so those mitigations are not needed to begin with.

eMudhra was a root CA. Their roots and intermediates were cross-signed by Sectigo since it was a new(-ish) root CA (a comment on Reddit characterized eMudhra as a Sectigo reseller, but I can't find verification of that), but I don't know to what extent that was done as a result of Sectigo's own evaluation vs. some internal process of a larger entity like the CA/Browser Forum. (Without cross-signing, it's difficult for a new CA to operate, so I imagine there must be some process by which a particular existing-CA cat is belled to be the cross-signer.)

This all day. There is no reason I should have to go through a third-party to get a certificate just to distribute a key for secure communications (which is all a DV certificate is good for) if I already own a domain, or can get the domain owner to publish my TLSA record in theirs (which should be no more onerous than publishing the server A record, which they already have to do).

The reason we don't have DANE support in browsers is of course because Google decided not to implement it in Chrome, because (ultimately) the key lengths securing the root DNS server zones weren't large enough to suit them (at the time, 1024 bits):

https://www.imperialviolet.org/2015/01/17/notdane.html

And if Google wasn't going to do it, it didn't make sense for any other browser to do it either.

However, I believe the root zone keys are now longer, so I could (potentially) see Google implementing DANE in Chrome now, maybe with a Chrome-specific restriction of "TLSA records that have keys under 2048 bits in their chain of trust are ignored" (since the root zone keys are not the only keys in the chain and they want to eliminate 1024-bit RSA from Chrome). And if Google does it in Chrome, then everybody else has to do it too, so the situation flips.

> LLMs aren't mapping applications, they're reasoners.

No they aren't. They're statistical token generators. They do not understand concepts such as "distance from a given location or coordinate point". If you're lucky you might ask it something likely to appear nearly verbatim in its training data, like "Chinese restaurants in Midtown Manhattan", and get back a reasonably accurate list, but it does not understand what a "Chinese restaurant" is, or what "Midtown Manhattan" is, or that one relates to the other in any way other than both appearing statistically associated with another set of tokens when they appear near each other.

What I've seen more than anything else is that Kubernetes built an ecosystem (of contributors and users, but also of companies invested in its success) that none of its competitors could or would. There was apparently a faction within Google that believed open-sourcing Kubernetes was a mistake because Google would have made more money keeping it in-house, but in terms of the success of the project I think it was entirely the right call, as was creating a foundation to maintain and promote it. Look at the history of its competition:

* DC/OS was always its own thing and as time went on, eventually Mesosphere was basically the sole maintainer of the underlying Mesos. Very little external contribution.

* OpenShift was different from Mesos and basically maintained only by Red Hat from the Makara acquisition (sometime in 2010 I think) to about mid-2015 (i.e. the point where they ripped out most of the OpenShift-native process isolation and orchestration and replaced it with Docker and Kubernetes). Pre-Kubernetes OpenShift frankly struggled to catch on and again, basically everybody who cared about developing it worked for one company.

* CoreOS was developing fleet in the open but dropped it outright when Kubernetes was released. The phrase I heard there was "We started to say something and Google finished our sentence." They pivoted to Kubernetes for orchestration so hard it was kind of awkward talking to customers who used fleet after that. In theory somebody could have picked it up like Kinvolk picked up rkt for awhile (and later CoreOS Linux as Flatcar), but as far as I know nobody ever made a serious effort to do so.

* Docker released Docker Swarm shortly after Kubernetes was released -- yet another one-company product. (I still don't really understand why they released Swarm -- for simple workloads, Docker Engine and Docker Compose were enough, and for more complex ones Docker Engine was, at that time, still the sole underlying runtime in Kubernetes. There were already two distinct orchestrators on the market, one from a much larger company with a lot more operational experience running containerized workloads than Docker had. What was their thought process?)

* HashiCorp released Nomad well after Kubernetes but not only was it another sole-corporate-maintainer orchestrator, it deliberately omitted a lot of the basics Kubernetes included like service discovery in an effort to stay simple -- so in very few cases was Nomad alone actually enough to orchestrate workloads (nor was it intended to be, as the Nomad engineers in the ~1.0 days would have been first to tell you). Past a point this made Nomad more work to get running and keep running than Kubernetes was.

The flip side is, I don't think a purely community-developed orchestrator would have won, even with a foundation backing it. It's not the corporate backing that's the issue, it's the lack of diversity in that corporate backing.

Tom Segura has a standup bit in one of his specials about cop reality shows, and how people think talking to the cops is going to work out great for them. "Lawyer up. You can't handle that s**. Everybody's like, 'I'm gonna talk to the cops, and straighten this whole thing out.' You're gonna do 25 to life. Have fun with that, man."

> When you read plenty of papers you aren't going to read them again to cite them.

But in fact I do exactly that, exactly because experience has taught me that my memory of what is in a paper is fallible and I should at least cursorily review what I'm citing. In a few cases I've even just deleted something entirely because my premise was based on a recollection of what I intended to cite that was subtly wrong enough to fatally undermine my entire thesis.

I'm not saying you have to read an entire paper over completely every time you cite it but at least pulling it up and reviewing the parts that are informing your argument is definitely a best practice.

What people currently refer to as "generative AI" is statistical output generation. It cannot do anything but statistically generate output. You can, should you so choose, feed its output to a system with actual operational capabilities -- and people are of course starting to do this with LLMs, in the form of MCPs (and other things before the MCP concept came along), but that's not new. Automation systems (including automation systems with feedback and machine-learning capabilities) have been put in control of various things for decades. (Sometimes people even referred to them in anthropomorphic terms, despite them being relatively simple.) Designing those systems and their interconnects to not do dangerous things is basic safety engineering. It's not a special discipline that is new or unique to working with LLMs, and all the messianic mysticism around "AI safety" is just obscuring (at this point, one presumes intentionally) that basic fact. Just as with those earlier automation and control systems, if you actually hook up a statistical text generator to an operational mechanism, you should put safeguards on the mechanism to stop it from doing (or design it to inherently lack the ability to do) costly or risky things, much as you might have a throttle limiter on a machine where overspeed commanded by computer control would be damaging -- but not because the control system has "misaligned values".

Nobody talks about a malfunctioning thermostat that makes a room too cold being "misaligned with human values" or a miscalibrated thermometer exhibiting "deception", even though both of those can carry very real risks to, or mislead, humans depending on what they control or relying on them being accurate. (Just ask the 737 MAX engineers about software taking improper actions based on faulty inputs -- the MAX's MCAS was not malicious, it was poorly-engineered.)

As to the last point, the burden of proof is not to prove a nonliving thing does not have mind or will -- it's the other way around. People without a programming background back in the day also regularly described ELIZA as "insightful" or "friendly" or other such anthropomorphic attributes, but nobody with even rudimentary knowledge of how it worked said "well, prove ELIZA isn't exhibiting free will".

Christopher Strachey's commentary on the ability of the computers of his day to do things like write simple "love letters" seems almost tailor-made for the current LLM hype:

"...with no explanation of the way in which they work, these programs can very easily give the impression that computers can 'think.' They are, of course, the most spectacular examples and ones which are easily understood by laymen. As a consequence they get much more publicity -- and generally very inaccurate publicity at that -- than perhaps they deserve."

> I wish I could hammer one thing through the skull of every "AI SAFETY ISNT REAL" moron: if you only start thinking about AI safety after AI becomes capable of causing an extinction level safety incident, it's going to be a little too late.

How about waiting till after "AI" becomes capable of doing... anything even remotely resembling that, or displaying anything like actual volition?

"AI safety" consists of the same thing all industrial safety does: not putting a nondeterministic process in charge of life- or safety-critical systems, and only putting other automated systems in charge with appropriate interlocks, redundancy, and failsafes. It's the exact same thing it was when everybody was doing "machine learning" (and before that, "intelligent systems", and before that some other buzzword that anthropomorphized machines...) and not being cultishly weird about statistical text generators. It's the kind of thing OSHA, NTSB and the FAA (among others) do every day, not some semi-mystical religion built around detecting intent in a thing that can't actually intend anything.

If you want actual "AI safety", fund public safety agencies like NHTSA and the CPSC, not weird Silicon Valley cults.

Why did the Pacific tectonic plate suddenly change direction 50 million years ago?

It’s also already becoming an issue for open-source projects that are being flooded with low-quality (= anything from “correct but pointless” to “actually introduces functional issues that weren’t there before”) LLM-generated PRs and even security reports —- for examples see Daniel Stenberg’s recent writing on this.

Ludicity wrote about exactly this a little while back:

https://ludic.mataroa.blog/blog/you-must-read-at-least-one-b...

"...There are fencers that seriously train that can barely score a point on me. I can barely score against the top guy in Australia. That guy can barely score against someone trying to make the Olympics, and that guy can probably barely score against the guy that actually won the whole thing."

Given that part of those "safeguards" were enshrining weird AI doomer logic in a federal agency's mission and trying to put a doomer in charge of enforcing it, some of them could use dismantling.

My vague recollection is that that concern was that the etcd store (specifically the keys pertaining to the Vault pod spec) could be modified in some way that would compromise the security of the encrypted Vault store when a Vault pod was restarted. It's been a long time since I remember that being a live concern though, so I've mostly recycled those neurons...

Not necessarily (although that doesn't necessarily mean I think this is OK). Payment-card-based verification is a longstanding method of doing prima-facie verification like this. When you give your credit card, you give your billing address and typically your phone number -- if the postal code is a US address and the phone number is a US area code and everything else is consistent with that, that might be all the KYC required. If you appear to be a foreign national operating outside the US, they can flag that and require additional paperwork only then.

This proposed rule looks to me like it basically requires providers to come up with their own verification plans, which may then differ from provider to provider, so as to be "flexible and minimally burdensome to their business operations".

[note for the following: I am not a lawyer. The following is not legal advice. Do not fold, spindle or multilate. Do not taunt Happy Fun Ball.]

The real danger, I think, with things like this is, there's an executive order that was issued, but it further specified a rulemaking process be conducted to determine the actual regulations that define compliance. The link in the title is to the proposed rule. There's nothing that says any amount of prior public input will necessarily influence the details of the final rule, or that rule can't change in the future through another rulemaking process, and if it does the only way to challenge it is either to sue the agency on the grounds that it exceeded its discretion (e.g. by making rules that require unconstitutional things) or that the enabling executive order is itself unconstitutional -- but these kinds of federal cases have a pretty high bar for what's called "standing" (the legal grounds to bring a particular lawsuit): you pretty much have to suffer concrete harm or be in obvious and imminent danger of suffering it to a grievous degree. (This is one reason you hear about "test cases" -- often somebody will agree to be the goat who is denied something, fined, or even arrested and convicted of a crime, so that standing to sue to overturn the law can be established.) Other times, if a lot of potential defendants already have standing, a particularly sympathetic defendant will be selected for the actual challenge. The US federal courts are also deferential to "agency discretion" by default, as a matter of doctrine.

What happens all too often with these things is, the initial rulemaking is pretty reasonable, and the public outrage (if there was any) dissipates. Then three years (or however long) on, the next rulemaking imposes onerous restrictions and strict criteria, and people suddenly (relatively speaking) wake up and find they're now in violation of federal regulations that they were in compliance with last week. (This is one reason public-interest groups are so critical -- they have the motivation and sustained attention to comb the Federal Register for announcements about upcoming rounds of rulemaking on various topics.)

IBM didn't just fork Vault to make a statement -- IBM Cloud Secrets Manager was (openly) built directly on Vault OSS.

Analyst consensus I've seen on long-term price has been floating around $32-34 per share. Take that with as much salt as you think it needs but it's at least interesting that it's within shouting distance of (but not over) the IBM offer.

Almost all the talk I saw internally, from well before to well after the license change, about competitors "taking advantage" of our open-source versions was about TFC competitors like Spacelift, Scalr, etc. and Terraform OSS. The Vault competitor mentioned most often was Akeyless but for reasons less like the TFC competition. I saw IBM Cloud Secrets Manager mentioned maybe once or twice.

I'm sure IBM Cloud's Vault offering was part of the decision, but from where I was sitting, it didn't look like the reason or even the primary reason.