111–120 of 181 posts
Earlier quoted context omitted.
Yep: "don't deploy DNSSEC, rely on TLS"
TLS security is rooted in DNS. It's ACME DNS-01. If your threat model includes nation states, this is a non-solution
Earlier quoted context omitted.
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 up…
Earlier quoted context omitted.
They serve different purposes. DoH protects DNS information while in flight. DNSSEC cryptographicly signs DNS records so they can be validated as being created by the owner of the domain. With only DoH you can be assured of privacy in flight and that the response hasn't been changed in flight; however, you don't know that the records on the server you connected to have not been manipulated.
The motivating use case for "cryptographically signing DNS records so they can be validated as being created by the owner of the domain" was the protection of those records in flight, which is something DoH does. A reminder that DNSSEC's "cryptographic security" coalesces to the single AD=true bit in the DNS header by the time DNS responses hit your browser; DNSSEC is a server-to-server protocol. So in almost all cas…
According to the original DNSSEC RFC, RFC2065, the purpose of DNSSEC is to provide data origin integrity and authentication. It also states "In addition, no effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC 1825].)" IPSEC didn't end up providing that role but DoH does. It doesn't address the issue of data origin integrity though.
Earlier quoted context omitted.
The US seizes the cryptographic material for a US based root, issues keys and certificates for the domains it wants to compromise and intercepts and modifies the traffic for targeted users. There's some additional asterisks around not getting caught and certificate transparency logs and browser reporting structure, but for many classes of devices, it will suffice to simply also hijack the domains used for requesting…
If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel. If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it.
ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures.
Finally, glue records aren't signed!
Earlier quoted context omitted.
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 up…
Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
I want a version of Web PKI strong enough that I can turn off my tablet for a year, turn it back on in a coffee shop, apply automatic updates, and not have my web traffic monitored, even if I'm gay and the coffee shop is in Saudi Arabia.
From what I can see, DNSSec+CAA+.com+US CA+US hosting for the Android update server does the trick. No version of CT does.
Earlier quoted context omitted.
The TLD registrar has enormous impact on you regardless of DNSSEC, and people just seem to put up with it, much as they put up with having an awful US state government, or a terrible HOA, or dozens of other problems. For ccTLDs you could hope, especially if you are a citizen of the country encoded and it's a democracy, that you can vote for governments who require the TLD registrar to meet your needs. Will that work?…
The important stuff is not just websites I host, but also websites I visit. And in all the scenarios you mention, I (and everyone else) would know that it happened very clearly, as it is basically denial of service attack. Even if this is a takeover event with almost-instantaneous replacement with the phishing page, the website owner would detect this and if the website is at least a bit popular, the news would defin…
Not only is your claim obviously not true in principle, we know it's not true in practice, disrupted DNS causes real issuances which are let's say... suspicious. They're not mis-issuance under current policy because the Web PKI trusts the DNS, but they would trigger exactly the scenario you believe can't happen.
Earlier quoted context omitted.
Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
The example I gave was a router or gaming system updating itself (e.g. using CUrl) not a full browser. Don't strawman please - if my argument is as weak as you say, you shouldn't need to. I want a version of Web PKI strong enough that I can turn off my tablet for a year, turn it back on in a coffee shop, apply automatic updates, and not have my web traffic monitored, even if I'm gay and the coffee shop is in Saudi Ar…
Earlier quoted context omitted.
When criticizing DNSSEC, you can’t assume that the system for TLS certificates – i.e. CAs – is perfect. They both have their weak points and drawbacks. Both BGP and certificate issuance have bootstrapping problems, which are handled today by imperfect TOFU-like solutions. DNSSEC is, IMHO, perfectly positioned to solve both of those problems. I.e. use certificates all you like, but verify them by looking up the TLSA r…
People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and w…
Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.
Earlier quoted context omitted.
Yep: "don't deploy DNSSEC, rely on TLS"
TLS security is rooted in DNS. It's ACME DNS-01. If your threat model includes nation states, this is a non-solution
Earlier quoted context omitted.
The example I gave was a router or gaming system updating itself (e.g. using CUrl) not a full browser. Don't strawman please - if my argument is as weak as you say, you shouldn't need to. I want a version of Web PKI strong enough that I can turn off my tablet for a year, turn it back on in a coffee shop, apply automatic updates, and not have my web traffic monitored, even if I'm gay and the coffee shop is in Saudi Ar…
The Play Store has cert pinning, so this all works just fine in the scenario you're describing.
It's late and I maybe haven't been super constructive here, but I think when you try to write out the actual assumptions behind CT as the whole solution, you realize you've got something that mostly works assuming assuming assuming - and worse, we'll never do any better, because those assumptions are fundamental technical limits. DNSSec may be ugly but at least its problems (like validators failing open) are just deployment issues, not fundamental technical issues.
I'm sick and tired of using technologies that provide security or correctness subject to a long list of preconditions and ways for folks to tell me I'm using it wrong. To build secure systems, we need technology that provides correct security without so much asterisks and fine print.