Security/Reviews/DNSSEC-TLS

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]