5 ms·

> Who is your preference? The government? The registries? ICANN? No, silly: the domain owner! Something that's already possible with DANE: the domain owner get

by voidz 11y ago

> Who is your preference? The government? The registries? ICANN? No, silly: the domain owner! Something that's already possible with DANE: the domain owner gets to decide, as it should be, by publishing information about valid certification into the DNS. Of ALL options this one is the least crappy IMO.

ajross 11y ago
And who authenticates the domain owners? Your solution is basically "trust the registries" then. OK, fine. But they've screwed up in the past and they will in the future.
- voidz 11y ago
  huh? No, for DANE it is required to have DNSSEC in place. Also read the last sentence of my previous statement again.
  - realityking 11y ago
    And now you're trusting the registrar, the registry and ICANN. It's always pick a poison. Also, DNSSEC still has some severe issues in practice. I'd be glad if we could get DANE widely deployed for mail servers. Edit: Oh, and if you're not using a validating resolver yourself you're also trusting that you're ISP is using one and not manipulating the responses.
    - marcosdumay 11y ago
      > Oh, and if you're not using a validating resolver yourself you're also trusting that you're ISP is using one and not manipulating the responses. I really don't understand why people keep repeating that complaint. Of course, if you don't check the keys you don't get any security. How is that a problem of the algorithm? And how is that a problem on practice? If you want some real amount of security you check the keys, being them SSL certificates, DNSSEC signatures, or whatever else encryption system people put on place.
      - realityking 11y ago
        You're speaking from the perspective of somebody who could set this up for himself. "Normal" people don't know stuff like this, but we can't leave them unprotected. That's why DANE for mailserver is such an attractive target. They're usually run by people who know what they're doing and it helps bring a lot of infrastructure into place.
        marcosdumay 11y ago
        The point is that there's nothing for normal people to setup (or, at least, it does not have to be). Your email software should verify DANE keys, just like your browser verifies TLS keys. The fact that current software is hard of configure is just a symptom that it's badly designed. The only inherently hard thing in DNSSEC is distributing your domain data (not really harder than setting our server for TLS), and normal people do not do that.
  - TheSpiceIsLife 11y ago
    You still have to trust someone. I think the trust model is broken for the same reason it can be said three can keep a secret, if two of them are dead. How can humans create a software or hardware system that absolves us of the issue of trust, when people are, and have always, been up to no good. The courts are full of people who claim other people have acted outside of good judgement. I don't think it's possible to have trust without its opposite. I'd like to be proven wrong.
- 0x0 11y ago
  If the registry cannot be trusted, SSL kinda goes out the window anyways since a malicious MX DNS record or WHOIS email entry is usually sufficient to obtain a certificate. Since we already are at the point where the security of the system hinges on the registrar, why not at least limit the damage potential by only accepting certificates issued by the registrar in question? Instead of letting any CA under the sun ALSO issue these? PS: If certificate issuance was a required and expected task for all registrars, it could even lead to $0 certificates, which would surely boost HTTPS usage. It would even provide an incentive to pick a thorough registrar if you are concerned about security and validation, since no other entity could issue illegitimate parallel certs behind your back. Brings some meaning back to being a high quality authority (even charging more for more trust) instead of the race-to-the-bottom we have today. Sloppy registrar-CAs would lose business because their trustworthyness actually means something for once. (You wouldn't register your serious domain with a registrar known to have poor validation checks in place for issuing certificates, for example)
  - josteink 11y ago
    > If the registry cannot be trusted, SSL kinda goes out the window anyway You seem to have gotten things backwards. If the DNS is hijacked, SSL is the only thing protecting a visitor from being lured into the hijacked site. Connecting these two things into one makes SSL effectively worthless.
    - zwily 11y ago
      If DNS is hijacked, the hijacker could also get valid SSL certificates (using MX records to get confirmation emails, etc).
      - josteink 11y ago
        If it is a EV certificate, that would certainly not be sufficient.
    - 0x0 11y ago
      Hmm, I think it is you who have things backwards. They way it is now, hijacking DNS (between the domain NS servers and any CA) would allow an adversary to request and obtain an illegitimate certificate by way of domain validation. If the registrar is the only valid issuer of certificates, this loophole is closed since there is nothing for the CA to verify - the registrar already knows who the customer is and can offer certificate signing without an insecure DNS based domain validation. For end-users with a hijacked DNS, the registrar-issued SSL certificate would still protect the transmission, because the DNS-spoofing adversary would not be able to present a valid certificate signed by the registrar. In fact, in today's CA environment, if the DNS hijacker is playing ball with a rogue CA, they could also spoof the SSL. With my suggestion, they couldn't, unless the rogue CA is actually the registrar, because the browser would see that the SSL certificate was not signed by the appropriate registrar. You could create a DNS-style CA setup like this: * Browsers would ship with ONE root CA, the public key of the "." root zone operator * Each TLD ("com", "org" etc) has a CA signed by the root zone operator, valid only for signing TLD registrar CAs. The root zone CA could publish a signed list of TLD certificates daily/weekly/monthly (they shouldn't change too often and the number of entries would be relatively low). Anyone could compare notes and see if these change. There aren't any hidden intermediary CAs. Browsers could sync this list daily/weekly/monthly, the deltas should be minimal. ISPs could even provide mirror services, because the whole list is signed by the root zone operator anyways. * Each registrar under a TLD has a CA certificate signed by the TLD operator, valid for only signing secondary domains under the given TLD. (i.e. customer domains). Just like the RootZone->TLD signed list of CAs, the TLD CA operator could publish a signed list of registrar certificates daily/weekly/monthly (again, they shouldn't change too often and the number of entries would be relatively low). Again, anyone can compare notes and see if things change. No hidden intermediary registrars. Browsers could yet again sync this daily/weekly/monthly and ISPs can mirror the list since it's signed. * Registrants of customer domain ("example.com", "example.org" etc) can request a domain-specific CA at their registrar, and only at their registrar. This domain-specific CA is valid only for signing leaf domains, i.e. "www.example.com", "mail.example.com". With the domain-specific CA in hand, the customer can create their own leaf domain certificates "at home". The registrar should offer non-EV domain-CA certificates for free (there is no work to be done to validate domain ownership as the customer already has an account there), or charge a fee for EV certificates. * There needs to be a way to determine who is the valid registrar for a given domain. This could be for example a TLS-based machine-readable WHOIS service address operated by each TLD. The TLS-based WHOIS service would negotiate TLS with the same TLD-CA-certificate as specified in the root list. Thus, a browser can connect to the TLD's WHOIS service and validate that a given domain is under a given registrar, and that the leaf SSL certificate is signed by the domain CA certificate, which is signed by the registrar CA certificate, which is in the signed-by-the-TLD list of registrars, which is in the signed-by-the-root-zone list of TLDs. This stuff could also be cached at the ISP level because everything is chain signed. Maybe this is how DNSSEC works (I haven't looked into the details), but I think this would be a pretty neat way to limit the damage done by rogue CAs.
- nadams 11y ago
  And so have the CAs. I would have to think about it but I'm sure there is SOME way to verify someone (either in person or digitally). This process would only have to happen once to verify the CA cert for their domain. After that - if their CA cert is compromised it's not a big deal because it only affects one domain. Oh - and any hoster that allows it's employees to reset virtual machine passwords or make account modifications via email/support ticket should NOT be allowed to participate in this scheme.
  - deleted 11y ago
    [deleted]
Guvante 11y ago
You are assuming that DNS is a valid place to store security information. While it can be in many places it cannot be in general due to the lack of authentication. And if you require some level of authentication you are back to the same problem.
- voidz 11y ago
  I'm not assuming anything, and I disagree because I think it's a different problem, not the same one. Also, did you read my last sentence?
  - Guvante 11y ago
    Your phrasing is hard to follow. I was assuming you meant that all information necessary to validate the certificate is attached to the DNS record which is crazy as the primary reason for SSL certificates that are centrally signed is when you don't get the right DNS record for some reason (roughly speaking). If you are instead saying that you should avoid having a URL in the certificate itself, validate it as normal and then use the DNS record to match the certificate to the URL I guess that could work. However you still have the above problem where anyone who has a valid certificate at all can impersonate any website by injecting a DNS record.
whoopdedo 11y ago
In the early days of internet commercialization I thought issuing trusted certificates would ideally be provided by banks. Money transfers are all about trust and securing information, it seemed like a perfect fit. You get a smart card from your bank that holds their root certificates and pop that into any computer to authenticate an email or website. It also holds your private keys for authenticating yourself to others for online banking, voting, etc. Of course I've since learned how awfully inertial the banking industry is and that the security of financial transactions is a lot of hand-waving and wishful thinking. On top of that, there's outright corruption of banks profiting from theft and always cooperate with governments. So the answer is, you shouldn't have to trust anyone. The security infrastructure must be built assuming hostilities are everywhere. Any trust that is given should be limited to just what is necessary to accomplish the task at hand.

by voidz 11y ago

ajross 11y ago

And who authenticates the domain owners? Your solution is basically "trust the registries" then. OK, fine. But they've screwed up in the past and they will in the future.

voidz 11y ago
huh? No, for DANE it is required to have DNSSEC in place. Also read the last sentence of my previous statement again.
- realityking 11y ago
  And now you're trusting the registrar, the registry and ICANN. It's always pick a poison. Also, DNSSEC still has some severe issues in practice. I'd be glad if we could get DANE widely deployed for mail servers. Edit: Oh, and if you're not using a validating resolver yourself you're also trusting that you're ISP is using one and not manipulating the responses.
  - marcosdumay 11y ago
    > Oh, and if you're not using a validating resolver yourself you're also trusting that you're ISP is using one and not manipulating the responses. I really don't understand why people keep repeating that complaint. Of course, if you don't check the keys you don't get any security. How is that a problem of the algorithm? And how is that a problem on practice? If you want some real amount of security you check the keys, being them SSL certificates, DNSSEC signatures, or whatever else encryption system people put on place.
    - realityking 11y ago
      You're speaking from the perspective of somebody who could set this up for himself. "Normal" people don't know stuff like this, but we can't leave them unprotected. That's why DANE for mailserver is such an attractive target. They're usually run by people who know what they're doing and it helps bring a lot of infrastructure into place.
      - marcosdumay 11y ago
        The point is that there's nothing for normal people to setup (or, at least, it does not have to be). Your email software should verify DANE keys, just like your browser verifies TLS keys. The fact that current software is hard of configure is just a symptom that it's badly designed. The only inherently hard thing in DNSSEC is distributing your domain data (not really harder than setting our server for TLS), and normal people do not do that.
- TheSpiceIsLife 11y ago
  You still have to trust someone. I think the trust model is broken for the same reason it can be said three can keep a secret, if two of them are dead. How can humans create a software or hardware system that absolves us of the issue of trust, when people are, and have always, been up to no good. The courts are full of people who claim other people have acted outside of good judgement. I don't think it's possible to have trust without its opposite. I'd like to be proven wrong.
0x0 11y ago
If the registry cannot be trusted, SSL kinda goes out the window anyways since a malicious MX DNS record or WHOIS email entry is usually sufficient to obtain a certificate. Since we already are at the point where the security of the system hinges on the registrar, why not at least limit the damage potential by only accepting certificates issued by the registrar in question? Instead of letting any CA under the sun ALSO issue these? PS: If certificate issuance was a required and expected task for all registrars, it could even lead to $0 certificates, which would surely boost HTTPS usage. It would even provide an incentive to pick a thorough registrar if you are concerned about security and validation, since no other entity could issue illegitimate parallel certs behind your back. Brings some meaning back to being a high quality authority (even charging more for more trust) instead of the race-to-the-bottom we have today. Sloppy registrar-CAs would lose business because their trustworthyness actually means something for once. (You wouldn't register your serious domain with a registrar known to have poor validation checks in place for issuing certificates, for example)
- josteink 11y ago
  > If the registry cannot be trusted, SSL kinda goes out the window anyway You seem to have gotten things backwards. If the DNS is hijacked, SSL is the only thing protecting a visitor from being lured into the hijacked site. Connecting these two things into one makes SSL effectively worthless.
  - zwily 11y ago
    If DNS is hijacked, the hijacker could also get valid SSL certificates (using MX records to get confirmation emails, etc).
    - josteink 11y ago
      If it is a EV certificate, that would certainly not be sufficient.
  - 0x0 11y ago
    Hmm, I think it is you who have things backwards. They way it is now, hijacking DNS (between the domain NS servers and any CA) would allow an adversary to request and obtain an illegitimate certificate by way of domain validation. If the registrar is the only valid issuer of certificates, this loophole is closed since there is nothing for the CA to verify - the registrar already knows who the customer is and can offer certificate signing without an insecure DNS based domain validation. For end-users with a hijacked DNS, the registrar-issued SSL certificate would still protect the transmission, because the DNS-spoofing adversary would not be able to present a valid certificate signed by the registrar. In fact, in today's CA environment, if the DNS hijacker is playing ball with a rogue CA, they could also spoof the SSL. With my suggestion, they couldn't, unless the rogue CA is actually the registrar, because the browser would see that the SSL certificate was not signed by the appropriate registrar. You could create a DNS-style CA setup like this: * Browsers would ship with ONE root CA, the public key of the "." root zone operator * Each TLD ("com", "org" etc) has a CA signed by the root zone operator, valid only for signing TLD registrar CAs. The root zone CA could publish a signed list of TLD certificates daily/weekly/monthly (they shouldn't change too often and the number of entries would be relatively low). Anyone could compare notes and see if these change. There aren't any hidden intermediary CAs. Browsers could sync this list daily/weekly/monthly, the deltas should be minimal. ISPs could even provide mirror services, because the whole list is signed by the root zone operator anyways. * Each registrar under a TLD has a CA certificate signed by the TLD operator, valid for only signing secondary domains under the given TLD. (i.e. customer domains). Just like the RootZone->TLD signed list of CAs, the TLD CA operator could publish a signed list of registrar certificates daily/weekly/monthly (again, they shouldn't change too often and the number of entries would be relatively low). Again, anyone can compare notes and see if things change. No hidden intermediary registrars. Browsers could yet again sync this daily/weekly/monthly and ISPs can mirror the list since it's signed. * Registrants of customer domain ("example.com", "example.org" etc) can request a domain-specific CA at their registrar, and only at their registrar. This domain-specific CA is valid only for signing leaf domains, i.e. "www.example.com", "mail.example.com". With the domain-specific CA in hand, the customer can create their own leaf domain certificates "at home". The registrar should offer non-EV domain-CA certificates for free (there is no work to be done to validate domain ownership as the customer already has an account there), or charge a fee for EV certificates. * There needs to be a way to determine who is the valid registrar for a given domain. This could be for example a TLS-based machine-readable WHOIS service address operated by each TLD. The TLS-based WHOIS service would negotiate TLS with the same TLD-CA-certificate as specified in the root list. Thus, a browser can connect to the TLD's WHOIS service and validate that a given domain is under a given registrar, and that the leaf SSL certificate is signed by the domain CA certificate, which is signed by the registrar CA certificate, which is in the signed-by-the-TLD list of registrars, which is in the signed-by-the-root-zone list of TLDs. This stuff could also be cached at the ISP level because everything is chain signed. Maybe this is how DNSSEC works (I haven't looked into the details), but I think this would be a pretty neat way to limit the damage done by rogue CAs.
nadams 11y ago
And so have the CAs. I would have to think about it but I'm sure there is SOME way to verify someone (either in person or digitally). This process would only have to happen once to verify the CA cert for their domain. After that - if their CA cert is compromised it's not a big deal because it only affects one domain. Oh - and any hoster that allows it's employees to reset virtual machine passwords or make account modifications via email/support ticket should NOT be allowed to participate in this scheme.
- deleted 11y ago
  [deleted]

Guvante 11y ago

You are assuming that DNS is a valid place to store security information. While it can be in many places it cannot be in general due to the lack of authentication. And if you require some level of authentication you are back to the same problem.

voidz 11y ago
I'm not assuming anything, and I disagree because I think it's a different problem, not the same one. Also, did you read my last sentence?
- Guvante 11y ago
  Your phrasing is hard to follow. I was assuming you meant that all information necessary to validate the certificate is attached to the DNS record which is crazy as the primary reason for SSL certificates that are centrally signed is when you don't get the right DNS record for some reason (roughly speaking). If you are instead saying that you should avoid having a URL in the certificate itself, validate it as normal and then use the DNS record to match the certificate to the URL I guess that could work. However you still have the above problem where anyone who has a valid certificate at all can impersonate any website by injecting a DNS record.

whoopdedo 11y ago

In the early days of internet commercialization I thought issuing trusted certificates would ideally be provided by banks. Money transfers are all about trust and securing information, it seemed like a perfect fit. You get a smart card from your bank that holds their root certificates and pop that into any computer to authenticate an email or website. It also holds your private keys for authenticating yourself to others for online banking, voting, etc. Of course I've since learned how awfully inertial the banking industry is and that the security of financial transactions is a lot of hand-waving and wishful thinking. On top of that, there's outright corruption of banks profiting from theft and always cooperate with governments. So the answer is, you shouldn't have to trust anyone. The security infrastructure must be built assuming hostilities are everywhere. Any trust that is given should be limited to just what is necessary to accomplish the task at hand.