The answer is unequivocally yes: RISC-V is designed to be customizable and a vendor can put whatever they like into a given CPU. That being said, profiles and platform specs are designed to limit fragmentation. The modular design and core essential ISA also makes fat binaries much more straight-forward to implement than other ISAs.
You can choose to develop proprietary extensions, but who’s going to use them?
A great case study is the companies that implemented the pre-release vector standard in their chips.
The final version is different in a few key ways. Despite substantial similarities to the ratified version, very few people are coding SIMD for those chips.
If a proprietary extension does something actually useful to everyone, it’ll either be turned into an open standard or a new open standard will be created to replace it. In either case, it isn’t an issue.
The only place I see proprietary extensions surviving is in the embedded space where they already do this kind of stuff, but even that seems to be the exception with the RISCV chips I’ve seen. Using standard compilers and tooling instead of a crappy custom toolchain (probably built on an old version of Eclipse) is just nicer (And cheaper for chip makers).
Yes, extensions are perfect for embedded. But not just there.
Extensions allow you to address specific customer needs, evolve specific use cases, and experiment. AI is another perfect fit. And the hyperscaler market is another one where the hardware and software may come from the same party and be designed to work together. Compatibility with the standard is great for toolchains and off-the-shelf software but there is no need for a hyperscaler or AI specific extension to be implemented by anybody else. If something more universally useful is discovered by one party, it can be added to a future standard profile.
I don't think it is. There are many many cases where you do want to own them.
The people you rent yours from are making a shit load of money so it doesn't sound that bad of an idea
I buy lots of things from people who make a pile of money from low margin goods/services sheerly on scale. There are many things i could not reproduce more cheaply from constituent parts, even if i value my time at $0.
> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
Set your TTL to five minutes and/or hand over DNS management to a service provider.
> Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.
Didn't save Cloudflare from a bad TLS certificate being issued. I still think that reducing the number of bad actors from 300 to the root servers and your registrar is a meaningful reduction in attack surface.
> DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.
How would authenticating DNS records cryptographically not address cache poisoning, MITM, and DNS spoofing in relation to DNS lookups? Also, DNSSEC doesn't have to solve all problems to make it worth doing.
> Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around `dig ds +short`. You'll find it's a low single-digit percentage.
Yet you complain about DNSSEC being to hard to deploy and not getting enough deployment. Wouldn't it be nice if they could leverage that automatic signing to also generate TLS, SSH, and other certificates?
It can be used alongside WebPKI. And as someone who is worried about other protocols, it sure would be nice if I could setup DNSSEC for my domain and have clients pick up on that automatically.
I can't even follow your argument anymore. DNSSEC is proposed as a feature to make DCV certificates more difficult to misissue. But DCV misisuance is overwhelmingly caused by registrar ATO. DNSSEC therefore can't address most DCV misissuance. And it has no other mainstream security proposition.
That is obviously not a claim you can make of the WebPKI. Your problem here is that the WebPKI is a very large superset of the security capabilities of DNSSEC. Unlike with DNSSEC, people --- millions of them --- actually rely on it.
I'll rephrase the argument to make it more clear for you: Phishing attacks are far more common than HTTP MITM, so we don't need protection against HTTP MITM. If you think this conclusion doesn't follow from this premise, then what differentiates HTTP from DNS in your mind, because you are making this argument about DNS?
Neither DNSSEC nor the WebPKI are defenses against phishing. But phishing (registrar ATO more generally) is the dominant vector through which DNS spoofing occurs, and DNSSEC solely addresses DNSSEC spoofing.
No? This is the third attempt you've made at this faulty syllogism. If we simply can't resolve enough premises to hash it out, that's fine, we don't have to try to understand each other.
HTTPS also has expiring keys that also need to be rotated. Most people outsource this to a service provider for them - as is the case with DNS. It's weird how people gripe about standard cryptography/PKI when it comes to DNSSEC but not HTTPS.
Eric Rescorla's post, linked upthread, goes into detail about why "OS's and browsers" can't easily solve this problem without breaking the Internet for materially large fractions of their users. In practice, browsers that care about DNS security just use DoH.
It's a lot like HTTP and every other early internet protocol that existed before the crypto. Everyone agrees that it's a problem but fixing all the existing infra is really hard and expensive.
> DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.
It only provides privacy, it doesn't verify that the resolver didn't tamper with the record.
>to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged.
This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.
Who? Outside of DNS providers, which organizations would need an emergency response to the collapse of DNSSEC security? Be specific; name one. If TLS security collapsed, I could pick a company from the Fortune 1000 at random, and they'd have an emergency response going.
I don't see any indication that DNSSEC would have been relevant there? Their assessment was that that interception (and certificate issuance) were completed by redirecting traffic for the legitimate IPs to another destination. The DNS records continued to work as expected.
> real world compromises of major sites that don't use DNSSEC?
Without any other changes to this infrastructure DNSSEC by itself wouldn't have prevented this, but it could have been combined with something else like a CAA record.
Given the large amount of sites, including popular sites, that do not have DNSSEC today, I'd expect that if this was a real risk we'd see a decent number of instances where it occurred.
And yet I see zero. Is it possible that given other mitigations (like multi-perspective validation) and given other attack vectors (like account takeover), this isn't actually a problem?
You're doing a jazz-hands thing here where you equate a breach in DNSSEC (which virtually nobody uses), to a new susceptibility in the ordinary DNS (which everybody uses), such that an attacker could spoof arbitrary DNS lookups to arbitrary CAs. Obviously the two things aren't comparable.
When you make arguments like this, or the weird SSH argument you're making across the thread, or the weird "this would be good for Wikileaks" thing you did elsewhere, you clarify how tenuous your argument is. Remember, you're in the position of arguing that 95%+ of large site operators are wrong about this, and have been for decades, and you're the one who's right. That can definitely happen! But it's an extraordinary claim and your evidence thus far is pretty terrible.
You know the funny thing about this is that I have talked, relatively recently, to one of the very few cryptographers who was an author on a DNSSEC standard, and they wouldn't work for the interview I want to do --- they're not sold enough on DNSSEC anymore.
The broader answer is: the relevant RFCs weren't authored by cryptography engineers. This was a major problem in the "old" IETF, before the cryptographers "took over" tls-wg and CFRG.
At any rate, the reason I asked in that particular place on the thread was that the preceding comment was attempting to draw a line between "sysadmins" who hate DNSSEC and the serious technologists who like it a lot.
You are going to complain that the key sizes are too small despite the guidelines being updated a long time ago. Then you will argue adoption of larger keys sizes is to low. Then you will argue that we should just not sign domain name authority delegation records at all (i.e. DNSSEC) and that we should abandon shoring up authenticated DNS because there is no adoption.
You have any cryptographers that are satisfied with unauthenticated name server checks?
You got a point: 1k isn't great and of course mainstream cryptographers will advocate for higher. That doesn't change that it's still acceptable within the existing security model nor that better alternatives are available. The cryptographic strength of DNSSEC isn't a limiting factor that fatally dooms the whole project. We have to upgrade the crypto used in large-scale infrastructure all the time!
And yes, uptake of better crypto is poor but I find chicken-and-egg arguments disingenuous when coming from someone who zealously advocates to make it worse. Furthermore, your alternative is no signing of DNS records. Find me a cryptographer who thinks no PKI is a better alternative. I know DJB griped about DNSSEC when proposing DNSCurve, which protects the privacy of the payload but not the intergrity of the payload.
The question was "can you find me some reputable cryptographers that support your position?" which is just ad hominem and should be ignored as such, except it does indicate that the person asking it doesn't have any better argument than ad hominem.
I dont really think it is. The original person claimed that the reason dnssec was unpopular was due to FUD. I think in that context its a fair question to ask what experts think.
For it to be an ad hominem, the person has to claim that the argument is wrong because of who they are. But that is not the claim here. The claim is that their argument that dnssec hate is unjustified FUD is wrong because experts (who presumably by virtue of being experts) are not susciptible to FUD, also do not think dnssec is a good idea. Thus it is directly attacking the argument and not the person, and hence not an ad hominem.
Sorry, but I asked who's the most reputable cryptographer you can think of who publicly supports DNSSEC? I asked because we'd like to interview them on SCW.
More random complaints instead of engaging with the substantive question.
You replied to a two sentence post asking for a name. What do you expect to happen when you do that? If you want to debate the merits, reply anywhere else.
reply