5 ms·

Ok, what do you want to replace it with? You can't complain about the existing system without offering an alternative. Saying the existing system sucks doesn'

Ok, what do you want to replace it with? You can't complain about the existing system without offering an alternative. Saying the existing system sucks doesn't help move the Internet towards something better.

maxk42 8y ago
You could embed public keys in DNS records for one. But I'll admit I was hoping someone who understands security better than I do would jump in. All I know is that centralized certificate authorities act as choke-points malicious governments can use to censor information.
- snowwrestler 8y ago
  DNS is even more centralized and tied to governments than CA's are.
  - cryptonector 8y ago
    The WebPKI is easy to compromise because there are so many CAs and NameConstraints cannot be reliably used so the whole thing is not hierarchical. Certificate Transparency (CT) provides the ability to detect some CA abuses, but is not a magic bullet. DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult. DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed. So at least as to non-nation-state actors, DANE is already more secure than the WebPKI. QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones. In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.
    - JoshTriplett 8y ago
      > NameConstraints cannot be reliably used I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".
- detaro 8y ago
  What has that to do with TLS? TLS doesn't specify where you get information which certs to trust from (indeed your "put keys in DNS" proposal exists as a standard, to be used with TLS, but used by nobody for HTTPS because DNS is either untrusted or secured by even more centralized structures) And protocols are typically stacked cleanly enough that it'd not be a big problem to replace TLS if another standard comes along to replace it.
- cryptonector 8y ago
  That exists, and is called DNS-Based Authentication of Named Entities (DANE) [0], and there are proposals for making use of that in TLS. There is no need to start over for transport security. TLS 1.3 is very well designed and will eventually support DANE. [0] https://tools.ietf.org/html/rfc6698
  - tptacek 8y ago
    The "DANE" proposal has been around for over a decade, and was actually implemented (probably twice, but at least in Chrome) and then rescinded, because it in practice doesn't work. But even if it did work, it would still represent a further centralization of trust on the Internet, this time with the central authorities that matter being effectively controlled by governments. DANE is a dead letter.
    - cryptonector 8y ago
      DANE definitely works for SMTP. Chrome's efforts at stapling DANE failed, but I think for the wrong reasons.
      - tptacek 8y ago
        No. DANE did such a bad job for SMTP that the major email providers banded together and created an alternate, non-DNSSEC-dependent standard, MTA-STS, to work around it.
        cryptonector 8y ago
        I'm sorry, but that's nonsense. MTA-STS is about sites that are having trouble deploying DNSSEC. DNSSEC != DANE. DANE depends on DNSSEC.
        tptacek 8y ago
        No, sorry, the MTA-STS draft itself is clear about this distinction. Also, your argument is circular. DANE definitely does not "work" for SMTP. The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP! Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC. DANE is a dead letter. † I'm choosing words carefully
- netheril96 8y ago
  And DNS can be easily poisoned. China's GFW does DNS poisoning as the first step of blocking websites.
- rocqua 8y ago
  Certificate authorities are bad, but fixes are possible. First of all, we have Certificate Transparency. This allows people to notice CA's behaving badly. Secondly, we need certs to be signed by many different CA's. Note that this is just my idea, and I know of no intentions to standardize this. Currently, rescinding trust in a CA is a difficult and slow process. This is because rescinding a CA breaks a lot of infrastructure. If instead, certs were signed by multiple CA's, we could just drop a CA and most infrastructure should have signatures by other CAs. Moreover, if I decided I don't trust the Hong Kong Post-office as a CA, I could drop them from my CA store without breaking the web. Perhaps I could even mark it as 'suspicious' and get notified when a cert is only signed by suspicious CAs. By combing the two things, when a CA is compromised, Certificate Transparency should tell us about that in about a week, after which trust in that CA can be dropped almost immediately. Just CT isn't enough. Consider what would happen if CT shows Lets-encrypt or DigiCert is compromised. We'd be forced to slowly drop trust, to allow many sites time to migrate away. Without the ability to drop a CA "like it's hot" Certificate transparency is toothless. It defends against CAs acting selfishly because getting caught by CT is bad for a CA. However, CT does not defend against coercion or compromise of CAs by third parties. Those third parties don't care whether the CA gets damaged. Under the current system they can get at least a month of signed certs for whatever domain they want.
emilfihlman 8y ago
>You can't complain about the existing system without offering an alternative. Yes, you can, and yes, you should. Or are you saying you shouldn't file bug reports unless you can provide a patch? Get real.

maxk42 8y ago

You could embed public keys in DNS records for one. But I'll admit I was hoping someone who understands security better than I do would jump in. All I know is that centralized certificate authorities act as choke-points malicious governments can use to censor information.

snowwrestler 8y ago
DNS is even more centralized and tied to governments than CA's are.
- cryptonector 8y ago
  The WebPKI is easy to compromise because there are so many CAs and NameConstraints cannot be reliably used so the whole thing is not hierarchical. Certificate Transparency (CT) provides the ability to detect some CA abuses, but is not a magic bullet. DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult. DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed. So at least as to non-nation-state actors, DANE is already more secure than the WebPKI. QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones. In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.
  - JoshTriplett 8y ago
    > NameConstraints cannot be reliably used I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".
detaro 8y ago
What has that to do with TLS? TLS doesn't specify where you get information which certs to trust from (indeed your "put keys in DNS" proposal exists as a standard, to be used with TLS, but used by nobody for HTTPS because DNS is either untrusted or secured by even more centralized structures) And protocols are typically stacked cleanly enough that it'd not be a big problem to replace TLS if another standard comes along to replace it.
cryptonector 8y ago
That exists, and is called DNS-Based Authentication of Named Entities (DANE) [0], and there are proposals for making use of that in TLS. There is no need to start over for transport security. TLS 1.3 is very well designed and will eventually support DANE. [0] https://tools.ietf.org/html/rfc6698
- tptacek 8y ago
  The "DANE" proposal has been around for over a decade, and was actually implemented (probably twice, but at least in Chrome) and then rescinded, because it in practice doesn't work. But even if it did work, it would still represent a further centralization of trust on the Internet, this time with the central authorities that matter being effectively controlled by governments. DANE is a dead letter.
  - cryptonector 8y ago
    DANE definitely works for SMTP. Chrome's efforts at stapling DANE failed, but I think for the wrong reasons.
    - tptacek 8y ago
      No. DANE did such a bad job for SMTP that the major email providers banded together and created an alternate, non-DNSSEC-dependent standard, MTA-STS, to work around it.
      - cryptonector 8y ago
        I'm sorry, but that's nonsense. MTA-STS is about sites that are having trouble deploying DNSSEC. DNSSEC != DANE. DANE depends on DNSSEC.
        tptacek 8y ago
        No, sorry, the MTA-STS draft itself is clear about this distinction. Also, your argument is circular. DANE definitely does not "work" for SMTP. The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP! Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC. DANE is a dead letter. † I'm choosing words carefully
netheril96 8y ago
And DNS can be easily poisoned. China's GFW does DNS poisoning as the first step of blocking websites.
rocqua 8y ago
Certificate authorities are bad, but fixes are possible. First of all, we have Certificate Transparency. This allows people to notice CA's behaving badly. Secondly, we need certs to be signed by many different CA's. Note that this is just my idea, and I know of no intentions to standardize this. Currently, rescinding trust in a CA is a difficult and slow process. This is because rescinding a CA breaks a lot of infrastructure. If instead, certs were signed by multiple CA's, we could just drop a CA and most infrastructure should have signatures by other CAs. Moreover, if I decided I don't trust the Hong Kong Post-office as a CA, I could drop them from my CA store without breaking the web. Perhaps I could even mark it as 'suspicious' and get notified when a cert is only signed by suspicious CAs. By combing the two things, when a CA is compromised, Certificate Transparency should tell us about that in about a week, after which trust in that CA can be dropped almost immediately. Just CT isn't enough. Consider what would happen if CT shows Lets-encrypt or DigiCert is compromised. We'd be forced to slowly drop trust, to allow many sites time to migrate away. Without the ability to drop a CA "like it's hot" Certificate transparency is toothless. It defends against CAs acting selfishly because getting caught by CT is bad for a CA. However, CT does not defend against coercion or compromise of CAs by third parties. Those third parties don't care whether the CA gets damaged. Under the current system they can get at least a month of signed certs for whatever domain they want.

emilfihlman 8y ago

>You can't complain about the existing system without offering an alternative. Yes, you can, and yes, you should. Or are you saying you shouldn't file bug reports unless you can provide a patch? Get real.