3 ms·

RFC 6844 defines a DNS record (CAA) which supposedly allows you to restrict which CA's are allowed to issue a certificate for your domain. Of course, this is on

by chaz6 10y ago

RFC 6844 defines a DNS record (CAA) which supposedly allows you to restrict which CA's are allowed to issue a certificate for your domain. Of course, this is on the honor basis. https://tools.ietf.org/html/rfc6844 https://tools.ietf.org/html/rfc6844

rocqua 10y ago
That can be secured with DNS-Sec, leading to DANE. It is often suggested as either an addition or replacement for the CA system. However, this is basically the CA system in disguise. Instead of trusting CAs, we need to trust domain servers. Thing is, domain servers tend to be controlled by governments even more so than CAs. There are some other issues with the technical implementation of DNS-sec, though I do not recall them at this moment.
- chaz6 10y ago
  I think ultimately you end up having to have a web of trust, but this assumes that the devices of the people in your web have not been compromised (backdoored apps and/or crypto libs).
  - rocqua 10y ago
    I think a system like CAs or DNS-sec, with hierarchical trust is a good base. However, we'd need to add certificate transparency and 'triangulation'. Certificate transparency is a centralized way to detect wrongly-issued certificates. Triangulation is a peer-to-peer way, where a client asks a few other clients what certificate they have. I like a DNS-based approach, because it ensures only one authority can authorize a key, though it has the issue of often being a state-controlled authority.
    - chaz6 10y ago
      I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do not know (I have never met one of the root signers before), so you have no way to know if they or their equipment have been compromised by a state actor.
      - rocqua 10y ago
        Sure, the root keys of DNS are non-state operated, but they are used to sign the DNS-sec keys for the TLDs. These, in turn, are used to sign the keys for the nameserver responsible for serving the normal domain. For any country TLD domain (.us .uk .nl), those keys are held by a state actor. That TLD then gets to sign any lower level DNS servers. Say whomever controlled .com wanted to change the key for hackernews.com. They'd simply change the .NS record for hackernews.com to point to a different DNS box with different keys, that proxies DNS requests for the real server but re-signs them. It can then simply serve a new DANE record. (DANE records are the DNS-sec version of CAs). This is essentially the same procedure as a CA issuing a wrong certificate. The source of this problem is that you don't just need to trust the root DNS servers, but you also need to trust the TLD-servers that are signed by the root DNS servers. (And down recursively if there are more NS records in between)
      - xorcist 10y ago
        You already trust the DNS root, as long as domain names are what certificates are based on. If you can transfer a domain name illegitimately you will have no problem getting a completely legitimate certificate signed. But the fact that domain names are hierarchical means you have to trust one or two entities at most. That's why domain name theft is historically less common than illegitimate TLS certificates. You'll find all sorts of arguments that the CAs do more things than that and no end of security professionals who work for them. Some of these arguments are probably correct but that doesn't change the overall picture how a secure global TLS PKI should operate in the presence of domain names. It does the current system quite resistant to change however.
- leni536 10y ago
  For DV certs you need to trust CAs and domain servers. Trusting only domain servers is an improvement.
richardwhiuk 10y ago
I've thought for a while that CAs should be restricted to a certain subset of the DNS space. So say CNNIC should be limited to .cn. The US DoD should be restricted to .mil.us. Google's CA could have their root for .google. That way, we can add CAs and they can be trusted at the root for a small amount of space. Obviously, we'd need to do some amount of grandfathering, but CAs should know who they've issued for. Is there any reason this isn't plausible?
- dchest 10y ago
  There's a new Name Constraints TLS extension to implement it: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 See also https://wiki.mozilla.org/CA:NameConstraints https://wiki.mozilla.org/CA:NameConstraints
  - majewsky 10y ago
    This would be awesome for my company (SAP), since it could get its internal root CA into the standard set of root CAs, with the name constraint on the "sap" TLD. (Yes, that TLD is a thing.)
    - tialaramex 10y ago
      People looking after the Web PKI aren't interested in adding trust for such a root which doesn't deliver any new value to their ordinary users. The US Federal Government is about to try this too, and I predict they'll struggle to jump all the hurdles (this isn't the FPKI, that's separate). You can get an existing CA (or more than one if you're paranoid) to write you a name-constrained subCA certificate today instead. This will cost a lot of money, but if they're pointlessly running a TLD then SAP is already burning money, presumably they can just fork a few million extra onto the bonfire.
  - tialaramex 10y ago
    (Edited to explain about v509v3 name constraints) That's not a TLS extension, it's two separate things you've linked The first thing is a standard feature of X509v3, which doesn't help you at the root because although root keys are distributed in the form of x509v3 certificates for convenience, they aren't really treated as certificates, after all you're trusting them, if you can't trust the root then Game Over. We use these name constraints all the time, they often protect a corporate subCA. The second thing is a proposal to Mozilla policy from 2015, ie, if it was implemented, this would be a change to the behaviour of Mozilla's TLS client, most specifically Firefox. It isn't currently being discussed by m.d.s.policy, the group which decides Mozilla policy. If you care about Web PKI policy m.d.s.policy is basically the only place you can influence it, everybody else of any significance makes these decisions in private (e.g. Microsoft, Apple, Oracle) or takes their cue from m.d.s.policy (most Free Unices, more obscure browsers).

by chaz6 10y ago

rocqua 10y ago

That can be secured with DNS-Sec, leading to DANE. It is often suggested as either an addition or replacement for the CA system. However, this is basically the CA system in disguise. Instead of trusting CAs, we need to trust domain servers. Thing is, domain servers tend to be controlled by governments even more so than CAs. There are some other issues with the technical implementation of DNS-sec, though I do not recall them at this moment.

chaz6 10y ago
I think ultimately you end up having to have a web of trust, but this assumes that the devices of the people in your web have not been compromised (backdoored apps and/or crypto libs).
- rocqua 10y ago
  I think a system like CAs or DNS-sec, with hierarchical trust is a good base. However, we'd need to add certificate transparency and 'triangulation'. Certificate transparency is a centralized way to detect wrongly-issued certificates. Triangulation is a peer-to-peer way, where a client asks a few other clients what certificate they have. I like a DNS-based approach, because it ensures only one authority can authorize a key, though it has the issue of often being a state-controlled authority.
  - chaz6 10y ago
    I tend to like the DNS approach as it is supposedly non-commercial and non-state operated, but again you have to place your trust in a group of people you do not know (I have never met one of the root signers before), so you have no way to know if they or their equipment have been compromised by a state actor.
    - rocqua 10y ago
      Sure, the root keys of DNS are non-state operated, but they are used to sign the DNS-sec keys for the TLDs. These, in turn, are used to sign the keys for the nameserver responsible for serving the normal domain. For any country TLD domain (.us .uk .nl), those keys are held by a state actor. That TLD then gets to sign any lower level DNS servers. Say whomever controlled .com wanted to change the key for hackernews.com. They'd simply change the .NS record for hackernews.com to point to a different DNS box with different keys, that proxies DNS requests for the real server but re-signs them. It can then simply serve a new DANE record. (DANE records are the DNS-sec version of CAs). This is essentially the same procedure as a CA issuing a wrong certificate. The source of this problem is that you don't just need to trust the root DNS servers, but you also need to trust the TLD-servers that are signed by the root DNS servers. (And down recursively if there are more NS records in between)
    - xorcist 10y ago
      You already trust the DNS root, as long as domain names are what certificates are based on. If you can transfer a domain name illegitimately you will have no problem getting a completely legitimate certificate signed. But the fact that domain names are hierarchical means you have to trust one or two entities at most. That's why domain name theft is historically less common than illegitimate TLS certificates. You'll find all sorts of arguments that the CAs do more things than that and no end of security professionals who work for them. Some of these arguments are probably correct but that doesn't change the overall picture how a secure global TLS PKI should operate in the presence of domain names. It does the current system quite resistant to change however.
leni536 10y ago
For DV certs you need to trust CAs and domain servers. Trusting only domain servers is an improvement.

richardwhiuk 10y ago

I've thought for a while that CAs should be restricted to a certain subset of the DNS space. So say CNNIC should be limited to .cn. The US DoD should be restricted to .mil.us. Google's CA could have their root for .google. That way, we can add CAs and they can be trusted at the root for a small amount of space. Obviously, we'd need to do some amount of grandfathering, but CAs should know who they've issued for. Is there any reason this isn't plausible?

dchest 10y ago
There's a new Name Constraints TLS extension to implement it: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 See also https://wiki.mozilla.org/CA:NameConstraints https://wiki.mozilla.org/CA:NameConstraints
- majewsky 10y ago
  This would be awesome for my company (SAP), since it could get its internal root CA into the standard set of root CAs, with the name constraint on the "sap" TLD. (Yes, that TLD is a thing.)
  - tialaramex 10y ago
    People looking after the Web PKI aren't interested in adding trust for such a root which doesn't deliver any new value to their ordinary users. The US Federal Government is about to try this too, and I predict they'll struggle to jump all the hurdles (this isn't the FPKI, that's separate). You can get an existing CA (or more than one if you're paranoid) to write you a name-constrained subCA certificate today instead. This will cost a lot of money, but if they're pointlessly running a TLD then SAP is already burning money, presumably they can just fork a few million extra onto the bonfire.
- tialaramex 10y ago
  (Edited to explain about v509v3 name constraints) That's not a TLS extension, it's two separate things you've linked The first thing is a standard feature of X509v3, which doesn't help you at the root because although root keys are distributed in the form of x509v3 certificates for convenience, they aren't really treated as certificates, after all you're trusting them, if you can't trust the root then Game Over. We use these name constraints all the time, they often protect a corporate subCA. The second thing is a proposal to Mozilla policy from 2015, ie, if it was implemented, this would be a change to the behaviour of Mozilla's TLS client, most specifically Firefox. It isn't currently being discussed by m.d.s.policy, the group which decides Mozilla policy. If you care about Web PKI policy m.d.s.policy is basically the only place you can influence it, everybody else of any significance makes these decisions in private (e.g. Microsoft, Apple, Oracle) or takes their cue from m.d.s.policy (most Free Unices, more obscure browsers).