5 ms·

The DV CA space is such a mess. I still wish DV certificate issuance was the responsibility of the domain registrar, with technical measures taken to prevent co

by 0x0 9y ago

The DV CA space is such a mess. I still wish DV certificate issuance was the responsibility of the domain registrar, with technical measures taken to prevent competing registrars from misissuance. This way, you don't need to play whack-a-mole around your certificates, just pick a reputable registrar when you buy your domain, avoid the need to "prove" you hold the domain (your registrar control panel is today already the sole security barrier protecting your domain), and avoid the possibility that a third party can play the impostor game. And it would bring some meaning back to the reputation of different TLDs and their various registrars.

brightball 9y ago
CAA records help with that now. You can just specify your certificate issuer at the DNS level.
- deleted 9y ago
  [deleted]
- 0x0 9y ago
  See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub-CAs to behave. (Well, at least CT logs are becoming a thing now) It would also eliminate today's more or less awkward validation routines that depend on third parties querying DNS/HTTP/whois-email addresses. The registry has the definite database, mapping the domain to your account at your registrar, anyways. They should simply have a public key upload button next to your domain name in your registrar's domain name control panel that immediately returns an appropriate certificate, no further validation needed :)
  - zokier 9y ago
    > I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.
    - 0x0 9y ago
      Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request? Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?
      - toast0 9y ago
        Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.
        0x0 9y ago
        Yep, it's a race to the bottom for CAs to perform the absolute minimum work necessary, because otherwise competitors come in and make things easier for customers. Paying a premium for the services of a stricter CA currently has no benefits, since end-users have no way to evaluate whether a certificate is legitimate vs sloppily or maliciously issued by a different CA. Funny thing about ccTLDs are that end-users might actually have some sort of opinion one way or the other about their trustworthyness, foreign or not. At least a tld is somewhat more visible and relatable in URLs compared to unfamiliar CA company names.
        9y ago
  - toast0 9y ago
    > See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay. Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are not intended as a means to revoke previously issued certificates, only an indication of which CAs are _currently_ allowed to issue new certificates. That said, I agree with you, but the general consensus doesn't seem to, that we de facto trust registries/registrars as stewards of domain ownership, so we may as well de jure make them CAs, since they already have an account relationship.
    - 0x0 9y ago
      I found your last paragraph especially well phrased! You're also on point regarding the CAA records. But to me the current system still feels too reactionary. I'd love to see a system where we need to put less trust in all third parties playing by the rules pinkie-promise. Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I think we've just seen the tip of the iceberg yet.
      - zaarn 9y ago
        And all examples of CAs essentially no longer in business (or bought up by DigiCert).
        0x0 9y ago
        Yes, but after the damage was done and only because the damage happened to be uncovered.
        zaarn 9y ago
        Well, obviously yes. The CA/B mailing list can't do much about shady behaviour they don't know anything about. I do trust in Mozilla to ensure that the game rules for CAs are strict enough that my trust in the green lock isn't 0. It's not 100% either but it's above 50%. When I connect to a website and it has SSL, I'm fairly certain it's the right place. Most likely there will never be a replacement for it, any PKI requires some third party to vouch for an endpoint otherwise you get easy MitM (I believe there is a proof floating around somewhere from the area of Signal Theory).
  - feelin_googley 9y ago
    "They should have a public key upload button next to your domain name in your registrars domain name control panel..." What about putting the public key in a subdomain. DNSCurve uses this approach to encrypt DNS packets. If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same? Management is handled by a "forwarder" daemon that is placed between the nameserver or httpd and the internet. IMO, much less complex than SSL/TLS, x509 and commercial CAs and control over encryption does not require third parties.
    - zaarn 9y ago
      The issue is trust. Can you trust that the other end of the DNSCurve system is not operated by Mr. Evil? Can you do that automatically, ie, without human intervention at all? The CA-based PKI system allows one to trust that the endpoint of a website is who they say they are and not a middlebox manipulating traffic. Additionally guarantees are available through EV certificates which also tell you who is operating the endpoint. DNSCurvse is most likely not able to assure you that the response you got is really from the authorative nameserver. It can only tell you that it was encrypted but there is no identity assurance.
      - feelin_googley 9y ago
        "Can you do that automatically, ie, without human intervention at all?" Why not use something like SSH authentication keys to verify the endpoint? (e.g. ed25519 which can be generated very fast) Consider the vast number of endpoints that are now currently being verified using authentication keys. For something like encryption, I believe some human intervention will always be required. Only a human can answer the question: "Do you trust this?" The issue is which humans are intervening: (a) the humans at each endpoint, or (b) the humans at each endpoint plus third parties. Letting the www commercial CA vendors and commercial ad-supported www browser authors answer the question "Do you trust this?" on behalf of users is still human intervention. Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game". The third parties are not the ones with the need to encrypt. They stand nothing to lose if the encryption is defeated. Common sense suggests this is the wrong approach. (And that's ignoring the ever-increasing number of exposed flaws and "incidents" regarding www commercial CAs, like the one being discussed in this thread.)

by 0x0 9y ago

brightball 9y ago

CAA records help with that now. You can just specify your certificate issuer at the DNS level.

deleted 9y ago
[deleted]
0x0 9y ago
See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub-CAs to behave. (Well, at least CT logs are becoming a thing now) It would also eliminate today's more or less awkward validation routines that depend on third parties querying DNS/HTTP/whois-email addresses. The registry has the definite database, mapping the domain to your account at your registrar, anyways. They should simply have a public key upload button next to your domain name in your registrar's domain name control panel that immediately returns an appropriate certificate, no further validation needed :)
- zokier 9y ago
  > I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.
  - 0x0 9y ago
    Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request? Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?
    - toast0 9y ago
      Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.
      - 0x0 9y ago
        Yep, it's a race to the bottom for CAs to perform the absolute minimum work necessary, because otherwise competitors come in and make things easier for customers. Paying a premium for the services of a stricter CA currently has no benefits, since end-users have no way to evaluate whether a certificate is legitimate vs sloppily or maliciously issued by a different CA. Funny thing about ccTLDs are that end-users might actually have some sort of opinion one way or the other about their trustworthyness, foreign or not. At least a tld is somewhat more visible and relatable in URLs compared to unfamiliar CA company names.
        9y ago
- toast0 9y ago
  > See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay. Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are not intended as a means to revoke previously issued certificates, only an indication of which CAs are _currently_ allowed to issue new certificates. That said, I agree with you, but the general consensus doesn't seem to, that we de facto trust registries/registrars as stewards of domain ownership, so we may as well de jure make them CAs, since they already have an account relationship.
  - 0x0 9y ago
    I found your last paragraph especially well phrased! You're also on point regarding the CAA records. But to me the current system still feels too reactionary. I'd love to see a system where we need to put less trust in all third parties playing by the rules pinkie-promise. Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I think we've just seen the tip of the iceberg yet.
    - zaarn 9y ago
      And all examples of CAs essentially no longer in business (or bought up by DigiCert).
      - 0x0 9y ago
        Yes, but after the damage was done and only because the damage happened to be uncovered.
        zaarn 9y ago
        Well, obviously yes. The CA/B mailing list can't do much about shady behaviour they don't know anything about. I do trust in Mozilla to ensure that the game rules for CAs are strict enough that my trust in the green lock isn't 0. It's not 100% either but it's above 50%. When I connect to a website and it has SSL, I'm fairly certain it's the right place. Most likely there will never be a replacement for it, any PKI requires some third party to vouch for an endpoint otherwise you get easy MitM (I believe there is a proof floating around somewhere from the area of Signal Theory).
- feelin_googley 9y ago
  "They should have a public key upload button next to your domain name in your registrars domain name control panel..." What about putting the public key in a subdomain. DNSCurve uses this approach to encrypt DNS packets. If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same? Management is handled by a "forwarder" daemon that is placed between the nameserver or httpd and the internet. IMO, much less complex than SSL/TLS, x509 and commercial CAs and control over encryption does not require third parties.
  - zaarn 9y ago
    The issue is trust. Can you trust that the other end of the DNSCurve system is not operated by Mr. Evil? Can you do that automatically, ie, without human intervention at all? The CA-based PKI system allows one to trust that the endpoint of a website is who they say they are and not a middlebox manipulating traffic. Additionally guarantees are available through EV certificates which also tell you who is operating the endpoint. DNSCurvse is most likely not able to assure you that the response you got is really from the authorative nameserver. It can only tell you that it was encrypted but there is no identity assurance.
    - feelin_googley 9y ago
      "Can you do that automatically, ie, without human intervention at all?" Why not use something like SSH authentication keys to verify the endpoint? (e.g. ed25519 which can be generated very fast) Consider the vast number of endpoints that are now currently being verified using authentication keys. For something like encryption, I believe some human intervention will always be required. Only a human can answer the question: "Do you trust this?" The issue is which humans are intervening: (a) the humans at each endpoint, or (b) the humans at each endpoint plus third parties. Letting the www commercial CA vendors and commercial ad-supported www browser authors answer the question "Do you trust this?" on behalf of users is still human intervention. Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game". The third parties are not the ones with the need to encrypt. They stand nothing to lose if the encryption is defeated. Common sense suggests this is the wrong approach. (And that's ignoring the ever-increasing number of exposed flaws and "incidents" regarding www commercial CAs, like the one being discussed in this thread.)