7 ms·

> User can't expect that his DNS is reliable. Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to di

> User can't expect that his DNS is reliable. Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.

lathiat 8y ago
That inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it) While not perfect it’s generally quite true for the majority case.
- phicoh 8y ago
  Actually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread. I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver. So that means that if you care about DV security, you enable DNSSEC.
  - tptacek 8y ago
    DNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
    - phicoh 8y ago
      If we are talking about obtaining DV certificates, then why do you bring up the connection between a browser and Google DNS? The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures. By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates. That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours. The next step would be for CAs to honour DANE records.
      - tptacek 8y ago
        You brought it up, not me.
    - tialaramex 8y ago
      Although CAs don't (not can't, neither the CAB rules nor any major trust store programme requires you allow names without) require DNSSEC they absolutely can insist on figuring out whether a name is protected by DNSSEC and enforce that if so, since the root is signed and DNSSEC has a closed world assumption (we can get a definitive signed answer which says "No" this domain isn't signed). It's interesting, even though the $0 price isn't intended to be the main draw a large number of domains with broken DNS fixed it to get Let's Encrypt working rather than pay a CA that doesn't care...
      - tptacek 8y ago
        It wouldn't matter if a CA decided to require DNSSEC for all issued certs, because others (obviously including LetsEncrypt) do not.
        tialaramex 8y ago
        But checking CAA with DNSSEC is mandatory (this caused much feather spitting) So if you have DNSSEC you can deny all the CAs you don't trust. If a bad guy leaves the CAA record alone they can't get a cert. If they try to replace the CAA record or deny it exists they fail DNSSEC checks. If your chosen CA agrees to only use a method that's actually secured you get an actual bona fide panacea, for the very affordable price of deploying DNSSEC and CAA, automating cert issuance and getting your DNS config right.
        tptacek 8y ago
        There's so much brokenness here that it's hard to know where to start rebutting this. I took an hour to game through this with some people who actually work on CA initial identity verification security; here's where I land: * First, most CAs don't do DNSSEC today, or, if they do, do DNSSEC fail-open. * Second, CA's can already do multi-perspective DNS lookup, which means that a practical attack to defeat CAA over standard DNS requires an on-path attacker. But if the attacker is on-path, most of the mechanisms CAs use to validate a domain fail, even if you use DNSSEC. * Finally, there's already a replacement for all this stuff in progress: RDAP, a secure JSON API that allows data to be pulled directly from registrars. Every mainstream browser and every CA/B forum CA voted to add it to the BRs; it's going to be implemented. If you really believe that something like CAA is the future for DV certs, then it seems pretty obvious that RDAP is going to be the way that happens. DNSSEC is a dead letter.
andrewstuart2 8y ago
I think he makes a fair point. Browser vendors may be trusting CAs to do more due diligence on their DNS lookups than they might expect browser users to even be able to provide. I still think there's a better way, though. Surely it must be possible to do some consensus through WebRTC and end up with something that lets me run my own domain-specific CA, at least for DV certs.
vbezhenar 8y ago
I consider unreliable routers that deliver response from DNS to user, especially the last router. If that last router is controlled by attacker, he still can't break HTTPS.

lathiat 8y ago

That inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it) While not perfect it’s generally quite true for the majority case.

phicoh 8y ago
Actually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread. I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver. So that means that if you care about DV security, you enable DNSSEC.
- tptacek 8y ago
  DNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
  - phicoh 8y ago
    If we are talking about obtaining DV certificates, then why do you bring up the connection between a browser and Google DNS? The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures. By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates. That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours. The next step would be for CAs to honour DANE records.
    - tptacek 8y ago
      You brought it up, not me.
  - tialaramex 8y ago
    Although CAs don't (not can't, neither the CAB rules nor any major trust store programme requires you allow names without) require DNSSEC they absolutely can insist on figuring out whether a name is protected by DNSSEC and enforce that if so, since the root is signed and DNSSEC has a closed world assumption (we can get a definitive signed answer which says "No" this domain isn't signed). It's interesting, even though the $0 price isn't intended to be the main draw a large number of domains with broken DNS fixed it to get Let's Encrypt working rather than pay a CA that doesn't care...
    - tptacek 8y ago
      It wouldn't matter if a CA decided to require DNSSEC for all issued certs, because others (obviously including LetsEncrypt) do not.
      - tialaramex 8y ago
        But checking CAA with DNSSEC is mandatory (this caused much feather spitting) So if you have DNSSEC you can deny all the CAs you don't trust. If a bad guy leaves the CAA record alone they can't get a cert. If they try to replace the CAA record or deny it exists they fail DNSSEC checks. If your chosen CA agrees to only use a method that's actually secured you get an actual bona fide panacea, for the very affordable price of deploying DNSSEC and CAA, automating cert issuance and getting your DNS config right.
        tptacek 8y ago
        There's so much brokenness here that it's hard to know where to start rebutting this. I took an hour to game through this with some people who actually work on CA initial identity verification security; here's where I land: * First, most CAs don't do DNSSEC today, or, if they do, do DNSSEC fail-open. * Second, CA's can already do multi-perspective DNS lookup, which means that a practical attack to defeat CAA over standard DNS requires an on-path attacker. But if the attacker is on-path, most of the mechanisms CAs use to validate a domain fail, even if you use DNSSEC. * Finally, there's already a replacement for all this stuff in progress: RDAP, a secure JSON API that allows data to be pulled directly from registrars. Every mainstream browser and every CA/B forum CA voted to add it to the BRs; it's going to be implemented. If you really believe that something like CAA is the future for DV certs, then it seems pretty obvious that RDAP is going to be the way that happens. DNSSEC is a dead letter.

andrewstuart2 8y ago

I think he makes a fair point. Browser vendors may be trusting CAs to do more due diligence on their DNS lookups than they might expect browser users to even be able to provide. I still think there's a better way, though. Surely it must be possible to do some consensus through WebRTC and end up with something that lets me run my own domain-specific CA, at least for DV certs.

vbezhenar 8y ago

I consider unreliable routers that deliver response from DNS to user, especially the last router. If that last router is controlled by attacker, he still can't break HTTPS.