3 ms·

> Any of them, since DNSSEC validation doesn't occur in stub resolvers. By that logic, because someone could write a browser that will accept invalid certifica

> Any of them, since DNSSEC validation doesn't occur in stub resolvers. By that logic, because someone could write a browser that will accept invalid certificates and/or show everything as secure etc, TLS in general is fundamentally broken so we should never use it. A bad implementation isn't reason to abandon the concept.

AnimalMuppet 10y ago
In what ways is TLS fundamentally broken? (Not arguing, I really want to know. We're looking at moving to it from SSLv3 as I write this.)
- stephenr 10y ago
  Edit: TL;DR: I'm not saying TLS is fundamentally broken. Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible) Re-read what I wrote, and what I replied to. A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification. My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation. Let's try a different example separated from certificates to make it clearer: IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.
  - tptacek 10y ago
    It's not that stub resolvers don't do DNSSEC validation. They can't. They get a single bit in the header from their upstream recursive cache telling them whether validation succeeded or failed. That's it. If you want better than that, you can't use a stub resolver. You have to embed an entire recursive cache server in every endpoint.
tptacek 10y ago
I don't understand this objection. No, as a fact, DNSSEC resolution happens at DNS servers. No browser does DANE at all (the two that tried --- Firefox and Chrome --- rescinded their support). But when they do, they'll be using a stub resolver just like everyone else, because that is how the protocol is designed.

AnimalMuppet 10y ago

In what ways is TLS fundamentally broken? (Not arguing, I really want to know. We're looking at moving to it from SSLv3 as I write this.)

stephenr 10y ago
Edit: TL;DR: I'm not saying TLS is fundamentally broken. Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible) Re-read what I wrote, and what I replied to. A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification. My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation. Let's try a different example separated from certificates to make it clearer: IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.
- tptacek 10y ago
  It's not that stub resolvers don't do DNSSEC validation. They can't. They get a single bit in the header from their upstream recursive cache telling them whether validation succeeded or failed. That's it. If you want better than that, you can't use a stub resolver. You have to embed an entire recursive cache server in every endpoint.

tptacek 10y ago

I don't understand this objection. No, as a fact, DNSSEC resolution happens at DNS servers. No browser does DANE at all (the two that tried --- Firefox and Chrome --- rescinded their support). But when they do, they'll be using a stub resolver just like everyone else, because that is how the protocol is designed.