Security/Reviews/DNSSEC-TLS
From MozillaWiki
Contents
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
- after one good handshake (since stapling occurs inside handshake)
- 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)
- prevent misissuance of certificates.
- 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.
- Signatures are often valid for on the order of a month.
- 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).
- A hostname cannot have both a CNAME and a TLSA
- 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]