Security/Reviews/DNSSEC-TLS

From MozillaWiki
Jump to: navigation, search

DNSSec-in-handshake security review

Introduction

  • Introduce Feature
    • use DNSSEC to tell browser what TLS key to use instead of x509 certs
    • stapled into tls handshake, rather than actually being retrieved with the DNS protocol
  • Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
    • prevent misissuance of certificates.
      • after one good handshake (since stapling occurs inside handshake)
        • this limitation is similar to HSTS
    • Gives us the ability to accept non-CA-signed certificates (this is a policy decision) (alternative vs strengthening mechanism)
      • Even later, allows us to reject CA-signed-only certificates (but keeping the EV list, if we feel that EV remains effective)
  • What solutions/approaches were considered other than the proposed solution?
    • When will we do it through DNS, so the first connection is safe too?
  • Why was this solution chosen?

Threat Brainstorming and discussion of previously-considered threats (30-40 minutes)

These blended together as we discussed previously-considered threats.

    • A hostname cannot have both a CNAME and a TLSA
      • e.g. addons.mozilla.org is a CNAME pointing at addons.mozilla.com
      • So we have to verify both the signed CNAME chain, and the chain for the target hostname
      • Slightly worrisome that the user is implicitly trusting a TLD they might dislike, even if the owner of the site made the delegation decision.
    • No clear revocation mechanism.
      • Signatures are often valid for on the order of a month.
        • Helps keep underlying private key safe, by not encouraging dnssec keys to stay online.
    • Assertion: we are not adding any additional trust to registrars than we have in the past (bsmith).
      • bsmith says we need complete validation of the assertion
      • reduces the number of possible attackers: not all CAs; not even one CA; just the domain registrar (whom DV-issuing CAs have to trust anyway).
  • If you want EV, you have to use it in strengthening mode
    • Perhaps after TLS is established and validated, a secondary check (using the current model and maybe cross-signing or something) can be performed to "upgrade" the connection to EV UI.
    • We eventually want sites to require this mechanism in connections (and have clients stop connections if it is not present)
      • This will prevent cert misissuance
      • There needs to be a mechanism to stop requiring this, and it can be equivalent to HSTS (i.e. set a short expiration date)
  • David's code utilizes a third-party library ( http://www.nlnetlabs.nl/projects/ldns/ ) to validate DNSSEC chains and he found bugs already there (~4 in ~1 week of fuzzing)

Diversion: how to eliminate phishing

  • If EV is all about phishing, maybe homoglyph detection, safebrowsing, and browserid (sign-in and auth in browser chrome, not content) is better.

Conclusions / Action Items (10-20 minutes)

  • Investigate whether this mechanism is worse/better/same as DV certs from a identification and trust perspective [Sid]
  • Security review of the ldns APIs that David's code uses (a fraction of ~25k lines of source code) [David and Brian]