5 ms·

But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the

by 0x0 10y ago

But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
tptacek 10y ago
First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
- 0x0 10y ago
  Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
  - tptacek 10y ago
    Maybe we could actually fix the problem instead of just moving it around.
agwa 10y ago
Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
- Kadin 10y ago
  You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
  - tptacek 10y ago
    HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
  - agwa 10y ago
    The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.

by 0x0 10y ago

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

tptacek 10y ago

First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.

0x0 10y ago
Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
- tptacek 10y ago
  Maybe we could actually fix the problem instead of just moving it around.

agwa 10y ago

Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.

Kadin 10y ago
You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
- tptacek 10y ago
  HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
- agwa 10y ago
  The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.