Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNSSEC KSK rollover breaks DNS resolution for .nz domains

status.internetnz.nz

Post reply on HN
Print view View original

101–110 of 181 posts

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#101

Post by throwaway892238 »

oittaa wrote: post #53
davidu wrote: post #52

DNSSEC is easily the worst upgrade, multiplying complexity and brittleness, with the least amount of net benefit (without even adding encryption), that could have been solved in much simpler ways, that the Internet has ever attempted -- and that's including IPv6 (which is now quite workable). Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially add…

At this point it feels like DNS should be given to Cloudflare or Google and let them design it from scratch. I'm only half joking.

Or both.

The story of Ethernet is kinda interesting. Invented in 1974 at Xerox PARC, the inventors started a new company called 3COM in 1979, and worked with IEEE, as well as DEC, Intel, and Xerox (called the DIX - I'm not kidding) for all of them to join forces and support one new standard. IEEE project to standardize it started in 1980, and formal standard publication happened in 1983. International (ISO) publication was in 1989.

Business decides what becomes the new standard, because the biggest businesses are whom everyone is dependent upon. So the biggest companies do set the new standards. Google has been doing that for years, using its search market dominance and custom browser as carte blanche to shape the web as it sees fit. CloudFlare has come in the back door, and doesn't have anywhere near the same influence, but does control a powerful market segment that is growing. Add in the cloud providers, and that's most of whom actually matter in terms of where the web goes.

Where the "internet" (sans web) goes is, I think, more up to the operating systems and ISPs. But since everything has been pushed into the web to avoid the manipulation of the "middle boxes" (ISPs and corporate networks), the end result is the people who control 'the web' (Google and CloudFlare) can now dictate terms.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#102

Post by mjg59 »

matthew9219 wrote: post #99
mjg59 wrote: post #88

Earlier quoted context omitted.

Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.

That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open: > If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled. That means a global adversary need merely block the update channel to targeted devices and w…

You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#103

Post by matthew9219 »

mjg59 wrote: post #98
matthew9219 wrote: post #94

Earlier quoted context omitted.

> you can't fake the SCT entries without having access to the CT private keys. So... Governments like the US and China can fake the entries by using their police forces to seize the private keys? SCT has the same set of problems as TLS - any log will do, not just logs from countries you trust.

This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to p…

The crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#104

Post by mjg59 »

matthew9219 wrote: post #103
mjg59 wrote: post #98

Earlier quoted context omitted.

This is why multiple SCT entries are required. Could you subvert all of this with enough effort? Yes, and the same is true of dnssec. Any form of cryptographic validation is only as secure as the control of its private keys, but modern TLS is designed to require you to compromise at least 3 independent parties in the TLS ecosystem to provide a plausible fake. And at that point why not just get the browser vendor to p…

The crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.

Ok. That's an argument you can make. Now go back and make that in the first place rather than diverting everyone down an incredibly tedious demonstration of you making assertive statements that are just factually wrong. There's space to talk about what tradeoffs are reasonable here (eg, if this is something you're concerned about, you can pick a CA that's not in a hostile country, and you can enable certificate stapling at the cost of increased fragility and depending on some level of TOFU), but when you start the conversation by just being clearly wrong and then double down on that when multiple people suggest that you're wrong and point at resources indicating that you're wrong, you're not doing a great job of making that space available.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#105

Post by deschutes »

plugin-baby wrote: post #40
bombcar wrote: post #29

Earlier quoted context omitted.

Locked doors can help prevent the door from flying open in an accident, too.

And maybe make rescue more difficult after a crash?

Doors are part of the structure of the vehicle and must stay closed to do their job in a collision. To my understanding this is the primary if not sole reason doors lock after a few seconds in motion.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#106

Post by matthew9219 »

mjg59 wrote: post #102
matthew9219 wrote: post #99

Earlier quoted context omitted.

That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open: > If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled. That means a global adversary need merely block the update channel to targeted devices and w…

You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.

That's just not what's happening. Reread the conversation. I started from here:

> Certificate transparency is cool, but it's not clear it really works for many classes of devices

Smart TVs aren't some gotcha I'm throwing in at the end. It's literally the first thing I said about CT. CT works ok for mobile phones, laptops, and other devices where you can make certain assumptions about multiple networks and frequent updates. If you want a technology that doesn't require these assumptions, you want DNSSec.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#107

Post by belorn »

acdha wrote: post #50
belorn wrote: post #35

Earlier quoted context omitted.

Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. "Who cares about what people post to a forum?" was something I personally heard when I added https to one site. It was only really b…

> Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. I’m not sure what you’re basing that on but every claim is the opposite of my experience back then. Even in the 90s it was expecte…

I recall well those discussions. Web stores did indeed often use https to protect credit cards. The argument was however that physical stores did not need to have similar protection, and that the issue really was with the weak security of credit cards. HTTPS was a unstable solution for a problem which people argued should had been solved with the credit card system. Physical security devices was again lifted as the future solutions to this problem.

It should also be mentioned here that credit card numbers as a security token has actually slowly been phased out in favor of other forms of payment systems online, and many banks today implement additional security requirement if you pay with a credit card. Black market with stolen CC numbers, despite https use by web stores, used to be one of the biggest issues with the internet, so even with all the stores using https it wasn't a solution to that problem.

I remember people talking about performance issues with https until the early 2010. "Every single micro second slower means reduced sales" was something people was very concerned about. I even heard it from people during an IETF meeting. It was talked in similar tone to how people today talk about SEO.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#108

Post by nickf »

matthew9219 wrote: post #93
nickf wrote: post #91

Earlier quoted context omitted.

Clients do not get pre-certs. Those are generated by the CA, and submitted to the log in return for an SCT. Forging a ‘fake CT log’ isn’t possible, either. Nor do clients talk to CT logs, at all.

> Forging a ‘fake CT log’ isn’t possible, either Why do you think this isn't possible?

Aside from what mjg59 said, it's clear you don't quite understand how CT works. Logs are stood up and then go through a fairly rigorous acceptance process by Google (and Apple) before finally being used. 'Used' in that a CA can then submit pre-certs to it and include the resulting SCTs in signed certificates, making them functional on Chrome/Apple platforms. Even the CA using the log generally takes some communication with the log operator to ensure the right set of roots are trusted for submitted pre-certs.

CT logs are used by CAs, not clients. A 'fake' log isn't a thing.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#109

Post by matthew9219 »

mjg59 wrote: post #104
matthew9219 wrote: post #103

Earlier quoted context omitted.

The crucial difference is who decides which cryptographic entities to trust. With TLS and CT, the browser defines the list of entities and if 3 or more of those entities live in a hostile country, you can be compromised. With DNSSec and CAA, the site operator gets to define the list of entities.

Ok. That's an argument you can make. Now go back and make that in the first place rather than diverting everyone down an incredibly tedious demonstration of you making assertive statements that are just factually wrong. There's space to talk about what tradeoffs are reasonable here (eg, if this is something you're concerned about, you can pick a CA that's not in a hostile country, and you can enable certificate stapl…

It's the argument I made at the top:

> The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer.

It's probably fair to say I've been a bit over assertive about CT, but it's all in the margin to me. No amount of technical complexity can turn community trust into direct trust. TLS is a community trust model and DNSSec is a direct trust model. The fact that CT is a pretty good community trust model and that browsers have (so far) done a pretty good job at keeping the CT community small is interesting, but it doesn't turn community trust into direct trust. So while I'd agree it's an incredibly tedious tangent, I'd say it's tedious moreso because the pro-CT folks are missing the forest for the trees than for any technical details about CT.

Edit: because community trust fundamentally relies on the notion of the community taking action against bad actors. Whether it's a CA or a CT log provider, and whether it's malicious action or a bug or just ceasing to do business, community trust has a time axis where membership in the community changes and notions of keeping devices up to date and political struggles ("too big to fail") and the like that simply aren't needed in direct trust.

Re: DNSSEC KSK rollover breaks DNS resolution for .nz domains

#110

Post by AndyMcConachie »

tptacek wrote: post #73
matthew9219 wrote: post #72

Earlier quoted context omitted.

The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer. Most companies trust their home country as a matter of practicality. Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global ad…

All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.

How can you prove that all CAs log every certificate they produce?
Post reply on HN