7 ms·

> CAA (that little-known standard for enforcing which CAs can issue certs for your domain) I'm sure the CA's absolutely LOVE this - customers are signaling tha

by jb613 10y ago

> CAA (that little-known standard for enforcing which CAs can issue certs for your domain) I'm sure the CA's absolutely LOVE this - customers are signaling that they will stay with CA 'X'. Given 'vendor lockin' or 'guaranteed recurring revenue', cert prices would drop thru the floor for 1st year only for renewals to increase.

ivanr 10y ago
Maybe, but there's no memory effect associated with CAA and you can change your configuration it any time. You're not actually locked in.
- jb613 10y ago
  > with CAA and you can change your configuration it any time so too could an attacker. If an attacker is able to set HPKP, then they could just as easily reconfigure CAA to a CA that issues them a cert for your domain.
  - pfg 10y ago
    The attack described in the article (web server compromise) would not necessarily give you access to the DNS of your domain (that's putting a lot of eggs in one basket). It's certainly an effective defense-in-depth mechanism.
    - jb613 10y ago
      > It's certainly an effective defense-in-depth mechanism. 1) We've seen time and again that complexity is the enemy of security. Generally, the more moving parts, the more likely for another flaw. This is less defense-in-depth than it is added complexity. The attackers have time on their side to figure out where the next hole is. 2) The OP suggests that HPKP failed because of practical reasons (domain admins are scared to death of getting it wrong and bricking their site) - things like CAA only add to the complexity.
      - pfg 10y ago
        1) I don't see how it can possibly be worse than the status quo. CAs already rely on DNS for domain validation. This is just another DNS query, with the reply being a whitelist of permitted CAs, not a replacement for domain validation. If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA. 2) CAA was introduced in this discussion as a possible solution to the RansomPKP problem. It is not a requirement for HPKP and the only effect on HPKP it would have is to actually reduce the risk associated with that attack.
        jb613 10y ago
        > CAs already rely on DNS for domain validation Not all - only a subset of certs issued > If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA. because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself. > actually reduce the risk associated with that attack and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access
        pfg 10y ago
        > Not all - only a subset of certs issued I'm not sure I follow. My point is that if you're arguing that a DNS query is some kind of added complexity, then I have bad news for you, because DNS queries are already a part of all domain validation methods (whether it is email, HTTP, DNS, etc.) > because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself. This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process. It can help mitigate certain vulnerabilities in the domain validation process. For example, WoSign recently mis-issued certificates for github.com due to a bug in their domain validation system. If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued. CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA. In addition to that, as has been mentioned in this thread, it might be useful in mitigating RansomPKP to a certain degree in the future. > and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access No, you have not pointed that out. I have pointed out that you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain.
pfg 10y ago
CAA is just a DNS record that can be changed at any time, so there's no vendor lock-in. CAs that implement CAA request that record and check whether they're permitted to issue the certificate; if they're not, they should refuse issuance.
- jb613 10y ago
  1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record. 2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.
  - ivanr 10y ago
    For what it's worth, my impression is that CAA will be mandated by the CA/Browser forum at some point. But, indeed, that's the main weakness of CAA—it requires that substantially all CAs support it.
    - jb613 10y ago
      There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself. Look no further than at some of the past transgressions browsers let CA's get away with.
  - notatoad 10y ago
    >CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA. CAA seems like another good step that the browsers can demand after a CA fucks up - like google has mandated that some CAs publish Certificate Transparency logs after they've mis-issued a cert, they should also be requiring CAA on threat of being revoked from the browser's trust lists.

by jb613 10y ago

ivanr 10y ago

Maybe, but there's no memory effect associated with CAA and you can change your configuration it any time. You're not actually locked in.

jb613 10y ago
> with CAA and you can change your configuration it any time so too could an attacker. If an attacker is able to set HPKP, then they could just as easily reconfigure CAA to a CA that issues them a cert for your domain.
- pfg 10y ago
  The attack described in the article (web server compromise) would not necessarily give you access to the DNS of your domain (that's putting a lot of eggs in one basket). It's certainly an effective defense-in-depth mechanism.
  - jb613 10y ago
    > It's certainly an effective defense-in-depth mechanism. 1) We've seen time and again that complexity is the enemy of security. Generally, the more moving parts, the more likely for another flaw. This is less defense-in-depth than it is added complexity. The attackers have time on their side to figure out where the next hole is. 2) The OP suggests that HPKP failed because of practical reasons (domain admins are scared to death of getting it wrong and bricking their site) - things like CAA only add to the complexity.
    - pfg 10y ago
      1) I don't see how it can possibly be worse than the status quo. CAs already rely on DNS for domain validation. This is just another DNS query, with the reply being a whitelist of permitted CAs, not a replacement for domain validation. If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA. 2) CAA was introduced in this discussion as a possible solution to the RansomPKP problem. It is not a requirement for HPKP and the only effect on HPKP it would have is to actually reduce the risk associated with that attack.
      - jb613 10y ago
        > CAs already rely on DNS for domain validation Not all - only a subset of certs issued > If the CA fails to follow the whitelist, it's not worse than a CA that does not implement CAA. Without pointing out evidence that shows how this addition could make things worse, I don't think this is a good argument against CAA. because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself. > actually reduce the risk associated with that attack and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access
        pfg 10y ago
        > Not all - only a subset of certs issued I'm not sure I follow. My point is that if you're arguing that a DNS query is some kind of added complexity, then I have bad news for you, because DNS queries are already a part of all domain validation methods (whether it is email, HTTP, DNS, etc.) > because the USER can't tell. The user is under the impression of increased security (because upgrading to browser version X.Y said it now supports CAA) yet the user doesn't know which cert was issued by a CA that checked CAA. And you can't add yet another indicator to the UI because the user is already numb from just the certificate itself. This has nothing to do with browsers. It's a mechanism to improve the CA domain validation process. It can help mitigate certain vulnerabilities in the domain validation process. For example, WoSign recently mis-issued certificates for github.com due to a bug in their domain validation system. If they had used CAA, and github.com had a CAA record indicating WoSign is not permitted to issue certificates for that domain, it's quite possible that the certificate would not have been issued. CAA is not a replacement for HPKP, and no one is arguing that. It's an useful defense-in-depth mechanism that could help prevent mis-issuance in many cases, but it's not (and never has been advertised as) a solution to the problem of a fully-compromised CA. In addition to that, as has been mentioned in this thread, it might be useful in mitigating RansomPKP to a certain degree in the future. > and as I tried to point out to you, it's ineffective against the threat of an attacker gaining access No, you have not pointed that out. I have pointed out that you need access to the DNS in order to change (and bypass) CAA records, whereas you only need control over the web server in order to obtain a certificate that can be used to ransom a domain.

pfg 10y ago

CAA is just a DNS record that can be changed at any time, so there's no vendor lock-in. CAs that implement CAA request that record and check whether they're permitted to issue the certificate; if they're not, they should refuse issuance.

jb613 10y ago
1) CAA tries to address the threat of attacker getting a cert issued for your domain - to carry out such an attack inherently requires taking over your DNS record or your domain account - if they can do this then they can also reconfigure your CAA record. 2) CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA.
- ivanr 10y ago
  For what it's worth, my impression is that CAA will be mandated by the CA/Browser forum at some point. But, indeed, that's the main weakness of CAA—it requires that substantially all CAs support it.
  - jb613 10y ago
    There's too many paying entities to appease - not just hundreds of CA's but various browser vendors as well. Either MUSTs will be changed to SHOULDs - or fragmentation of the CA/Browser body itself. Look no further than at some of the past transgressions browsers let CA's get away with.
- notatoad 10y ago
  >CAA requires the CA to perform additional operation (retrieve and check that DNS record) - not all of the 300-600+ CA's will do this - all it takes is 1 CA and the attacker will get his fraudulent cert from that CA. CAA seems like another good step that the browsers can demand after a CA fucks up - like google has mandated that some CAs publish Certificate Transparency logs after they've mis-issued a cert, they should also be requiring CAA on threat of being revoked from the browser's trust lists.