If you have evidence, I'm sure you can bring to the attention of the Mozilla Root Store Inclusion program and the CA/Browser forum. Moreover, "there are other criminals who have gotten away with much more" is not an argument.
I think the steel man version of the argument is: "You showed that there is no effective monitoring or transparency that me as a user can get, and as such, Where is the trust come from. What fundamentally causes Mozilla (or any) to trust CAs more than randomly distributed certificates."
The CA/Browser forum's requirement and enforcements such as this one (and against DarkMatter, CNNIC and the likes) give me the required confidence to trust them, even though I'd agree it's not a perfect process.
Your average user is unlikely to begin to understand why a CA would be trustworthy, and a web of trust model only works for social situations but not for certificate distribution.
"A moose once bit my sister. Therefore all meese must be sacked".
I have trouble seeing this as a steeled version of anything. "People have uncovered a flaw in the system, therefore the entire system is unfit for purpose" does not really make a compelling argument. It displays selection bias, hasty generalization, nirvana fallacy, and something about babies and bathwater.
If people have "uncovered a flaw", but there is reasonable expectation that the flaw is very widespread and broadly ignored, then there is a reasonable suspicion that the flaw is being weaponized in this case. This is why in many legal systems it is in fact a valid defense to note that the law you are being prosecuted under is not being broadly applied, implying state caprice and corruption.
I will argue it is not the a flaw in some random aspect of the system, but the main propose of the system. Which is to vet companies they trust to distribute it through CA signing.
Do you think I will buy from a restaurant after finding they had expired food? Good food is the reason I'm there in the first place.
> DNSSEC is a PKI that follows DNS delegation, and no CA can issue certificates out of scope by definition.
Sure, and with that you are forced to trust your name servers (and/or the registry's) and your TLD's and the roots'.
All that with little choice in the matter, and little to no transparency into the process.
Just one example - if your TLD leaks their keys, that's sufficient to forge all the replies a middleman would need and nobody would really notice.
With WebPKI you can use CAA records and Certificate Transparency logs, plus you can get some extra assurance from the fact that they have to comply with the policies set by independent trust stores.
> That alone should be enough to consider it a strictly better subset of the browser CA PKI model.
It's a subset that leaves out the parts that would make it better than WebPKI. Right now it just complements WebPKI, at best.
If the TLD leaks their keys, and an attacker can impersonate a registrar, you are screwed today. That's on top of the possibility that the CA -- no, any CA -- leaks their keys.
CAA and CT are absolutely wonderful initiatives and do a lot to keep the creaky CA PKI usable. But that's on top of the domain registry which underpins everything.
The registry control ownership of domains. With that comes an indirect power to control who can get domain validated certificates issued. Then on top of that we also have to trust the CA who only do the actual issuing.
That's just strictly worse for no upside other than historical reasons.
Look at the most popular protocols for domain issuance. It's variants of a simple theme, store-and-forward signed ascii messages. It's crypto every step of the way. Yet most of the large TLDs manage with less screwups than many of the CAs.
In my anecdotal experience both types of institutions are manned with very competent people, but I would not hesitate between the ccTLD and the CA which one to trust if given the choice.
> But that's on top of the domain registry which underpins everything.
Everything but trust. A registry lying to issue certificates for its domains will become visible real quick. If CT makes "creaky WebPKI usable" then DNSSEC is just unusable.
> Yet most of the large TLDs manage with less screwups than many of the CAs.
Hard to screw up what you don't have. Even if a bunch do implement DNSSEC, nobody has really trusted them with the task in a way that it'd actually matter.
TLD operators can't even mandate the use of DNSSEC by registrars, requiring audits is lightyears away in comparison. WebPKI at least does that.
Nobody in their right mind would be claiming an opaque system with zero oversight is somehow better for trust, than the alternative.
The above comment is not right. How do the registrar come into this?
I don't know what you base your experience on, but it is not representative of the better ccTLDs. The oversight there are beyond what you have in any CA. That much is a fact.
If you have specific criticism, feel free to ask any of the people concerned at for example the next IETF. In my experience criticism is welcomed and listened to. That is, indeed, what builds trust.
> The above comment is not right. How do the registrar come into this?
People often use their name servers (and possibly delegate a zone further) instead of adding their keys directly. Or at least people use their registrar's interface for managing those keys.
> The oversight there are beyond what you have in any CA. That much is a fact.
Absolutely not. There's no system for monitoring key (mis)usage at all. There isn't a way to mistrust anyone if they do violate any agreements.
Maybe you mean oversight internally by some ccTLDs, but that does not build trust externally.
> If you have specific criticism, feel free to ask any of the people concerned at for example the next IETF. In my experience criticism is welcomed and listened to. That is, indeed, what builds trust.
These issues have been described in detail, but you've skipped over them a few times now. Plus they are not for the IETF to solve really, as they mostly relate to the human concept of trust (or lack of it), not the raw technical cryptographical aspects.
What indeed would build trust would be adopting public audits, transparency and revocation methods from WebPKI.
Let's start by logging all zone files signed. The fact that this doesn't exist already shows how much worse DNSSEC is and don't skip this point this time.
No I don't have evidence - however logical deduction shows that the probability of this happening is high. Any system involving humans is fallible, so it would be naïve to think that it doesn't happen.
Or put another way: if I was the NSA or MI5 this is exactly how I would attack the problem of traffic interception or targeted black ops. Get a puppet CA via hook or crook.
Totally agree that "there are other criminals who have gotten away with much more" is not an argument; I'm not sure what that has to do with my comment? I'm certainly not suggesting that. If anything I suggest that such systems are pretty much broken by design (at least if you care about state actors / extremely well funded actors).
I already responded to your other comment here[1], however any lawyer would advise against making condescending statements to cops, judges or anyone else for that matter.
Further, no lawyer would advise making a statement such as "we've been asked to avoid discussing our legal structure because we may be punished by tax authorities", because the statement itself can be taken as an admission of wrongdoing.
I'm not seeing where she's provided answers to the questions that really matter. All she's done is to talk in a patronizing manner to the CA members regarding their inability to understand corporate structures, as well as never answering how or why a MITM companies' SDK ended up being embedded in their app.
Further, even in times of stress, lashing out isn't the best decision. If I were interrogated by a cop and I called them a bunch of names, I would attract additional charges, on top of being suspected of commiting the crime that I've been accused of.
To be fair they do say (without proof but that can be hard to provide) that the spyware was put there by a contract developer that was not authorized to add 3rd party tools but did anyway.
That being said, given how extremely evasive they were and the lack of any tangible proof, I don't think it is unreasonable to doubt this explanation (how come you think a contract dev implementing malware isn't grounds for a lawsuit, shouldn't that be an open and shut case?)
I have to say that even if the “rogue developer” story is accurate, the reaction to it is a little underwhelming. “Sure, our supposed E2EE software did some crazy sketchy shit including proxying trivially-decryptable network packets to god-knows-where through our servers, but, uh, that guy doesn’t work here anymore” is supposed to be satisfying?
I'm advising people for a long time now to make screenshots of emails etc. - at least have everything in writing, don't act on phone calls if you feel things are "in a grayzone" (happens often in startups).
Its pretty clear that a dev with a second degree in law still wouldn't have been able to determine whether companies that shared most of the same infrastructure and listed corporate officers were 3rd parties in the context of software, without grilling someone who may or may not be a Trustcor executive, may or may not be the past founder and may or may not be dead, where such a death neither implies nor dismisses the possibility that they are still running the company.
I wondered the same about those "audits". When we had to introduce SOX and had compliance audits, every moving of my small finger needed to be reviewed and documented and have a trail to a senior manager approving the move of my small finger.
She didn't lash out, everyone else did? She made it very clear numerous times that she didn't think the forum appropriate for discussion of speculation.
This response by Rachel McPherson from Trustcor definitely comes as lashing out"
> Apparently it may also come as a surprise to some readers and the researchers themselves that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have tragic modern histories of basic human rights violations. We are none of those things and our company does not identify with those values. Given this point above, why of all potential targets are these researchers interested in TrustCor? They could go after countries with human rights violations that have placed a CA in the program.
Not only "SDK ended up being embedded in their app" but why they had an unobfuscated version when everyone else has only an obfuscated version of that SDK.
It would require better societal structures and labor laws to address mental health, which requires political will. However, just like climate change, this is a thing where you'd have to make society pass through a local minima before reaching a global maxima, and as a result it is very difficult to put this in front of a politician even for the slightest bit of consideration.
And unlike the more vocal counterparts of minorities who take to the streets when they feel aggrieved, people with adverse mental health keep suffering in isolation, so it's difficult to make a political issue out of it in the first place.
PHPs model would be okay if they used green threads/goroutines. That way, you can have a far larger number of workers, as most of them are blocked on database connections or HTTP requests to other services.
It has proved successful so far. The shared-nothing, short-lived process avoids classes of issues such as with slow memory leaks, accidentally blocking event loops, and shared memory threading issues.
Most PHP sites will utilise php-fpm, so it isn't really true that each request will spawn another PHP process.
The language historically hasn't been that great, but its shared-nothing architecture has always been the good part.
Indeed. I turned mine off as soon as I saw Alexa transcripts being used in court cases. If one can't conspire to commit crimes in one's own home, where can you?
While I wouldn't put any authoritarian moves beyond China's reach, the ICP recordal mechanism already requires government approval.
In that case, isn't it better for user privacy (not that anyone cares about it in China) to receive an ICP recordal but then wait for an actual request from law enforcement to turn over the logs?
Also, while you wouldn't see anyone from Amazon or Cloudflare comment on your thread, both have the ability to stream logs to a destination, and that is also exposed to customers, so I don't think they needed to build anything else.
All of the sites served had an ICP license. This is separate, and the CDNs in China have regulations specific to CDNs they need to comply with.
At the time, Akamai also had the capability to stream logs, but the ministry of technology required a specific, custom interface to receive them, which required engineering work, especially to do it for an entire country without the customers configuring it themselves. I would be extremely surprised if it required no engineering work at Amazon or Cloudflare to deliver the logs in the way they requested.
