4 ms·

DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC the

DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https) DNSSEC is a Government-Controlled PKI [...] Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it. DNSSEC is Incomplete [...] In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)" DNSSEC is Unsafe Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/) DNSSEC is Cryptographically Weak That's only point with I agree.

tptacek 10y ago
Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.
icebraining 10y ago
How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
- garaetjjte 10y ago
  It is better in that we're eliminating CAs and limiting possibility of issuing malicious certificates to root domain owner.
  - tptacek 10y ago
    It does not do that. This is a misconception. It is not a little bit false; it is totally false. We will not stop having 1035 CAs if DANE is deployed. We will have more: one new one for each of the TLDs, plus a new one at the root.
    - garaetjjte 10y ago
      You can use TLSA PKIX-TA record to limit CA which can issue certificate for given domain. Also, if DANE is deployed, we can ditch CAs for non-EV certificates.
      - tptacek 10y ago
        First, no you can't, not with DANE: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Second: you already can limit which CAs can issue a certificate for your domain, without forklifting out the DNS: https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/Security/Public...
        deleted 10y ago
        [deleted]
        garaetjjte 10y ago
        Argument that "At the time, some 4–5% of users couldn't lookup that record; we assume because the network wasn't transparent to non-standard DNS resource types." doesn't make sense for DNSSEC, because it requires signed explicit information that record not exist. If server won't return it, then it is broken and needs to be changed. Yes, there is HPKP, but it is "Trust on First Use" and adds entropy for browser fingerprinting.

tptacek 10y ago

Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.

icebraining 10y ago

How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?

garaetjjte 10y ago
It is better in that we're eliminating CAs and limiting possibility of issuing malicious certificates to root domain owner.
- tptacek 10y ago
  It does not do that. This is a misconception. It is not a little bit false; it is totally false. We will not stop having 1035 CAs if DANE is deployed. We will have more: one new one for each of the TLDs, plus a new one at the root.
  - garaetjjte 10y ago
    You can use TLSA PKIX-TA record to limit CA which can issue certificate for given domain. Also, if DANE is deployed, we can ditch CAs for non-EV certificates.
    - tptacek 10y ago
      First, no you can't, not with DANE: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Second: you already can limit which CAs can issue a certificate for your domain, without forklifting out the DNS: https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/Security/Public...
      - deleted 10y ago
        [deleted]
      - garaetjjte 10y ago
        Argument that "At the time, some 4–5% of users couldn't lookup that record; we assume because the network wasn't transparent to non-standard DNS resource types." doesn't make sense for DNSSEC, because it requires signed explicit information that record not exist. If server won't return it, then it is broken and needs to be changed. Yes, there is HPKP, but it is "Trust on First Use" and adds entropy for browser fingerprinting.