7 ms·

Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. The sole raison d'être for the entir

Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. The sole raison d'être for the entire CA infrastructure is to prevent active MITM-style attacks. So from that perspective what you said is positively Orwellian. Noncritical name constraints absolutely do affect clients that don't support them. It reduces their security by making them vulnerable to MitM! The entire purpose of the critical flag was to allow evolving the PKI system without reducing security for existing systems. We ought not set the flag FALSE because the CA's big customers prefer flexibility to the security of the whole ecosystem. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win. A false dichotomy being imposed by a well-funded minority for which it serves their interests.

tptacek 14y ago
Non-critical nameExtensions protect Chrome, IE and Firefox. They don't protect Safari. Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari. NO nameExtensions protects nothing. Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.
- marshray 14y ago
  non-critical name extensions strictly dominate unconstrained certificates Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils? The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect. So, yeah, maybe it's more Overton than Orwellian.
  - tptacek 14y ago
    The hell? Marsh, Adam Langley is one of the good guys. The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.
    - marshray 14y ago
      Oh look, I have deep admiration for AGL. I like RMH too! I agree that they are "good guys". But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies. RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations. Therefore, users and developers of existing security products must oppose this violation of RFCs.
      - tptacek 14y ago
        You keep citing the RFC as if it mattered. What matters in reality are the judgements of Microsoft, Google, Mozilla, and Apple (the HTTPS cabal). That this is annoying does not change its underlying truth. Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure. The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
        ivanr 14y ago
        The RFC may or not matter, but what does matter is doing the right thing. For example, if critical Name Constraints are not universally supported, does that make it right to use the non-critical ones? I don't think so. If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.

tptacek 14y ago

Non-critical nameExtensions protect Chrome, IE and Firefox. They don't protect Safari. Critical nameExtensions protect Chrome, IE, Firefox, and (because Safari will barf on them) Safari. NO nameExtensions protects nothing. Adam's point is simply that non-critical name extensions strictly dominate unconstrained certificates. His point isn't Orwellian at all.

marshray 14y ago
non-critical name extensions strictly dominate unconstrained certificates Don't you see how, once again, the CA industry has shifted the debate from the level of security everyone expected them to provide all along to another lesser of two evils? The discussion isn't about whether or not we must require name constraints on 3rd-party sub-CAs to be marked 'critical'. The issue is that the world of SSL/TLS client application users and developers believe, expect, and rely upon the non-proliferation of private keys with the ability to forge identities for the servers to which they connect. So, yeah, maybe it's more Overton than Orwellian.
- tptacek 14y ago
  The hell? Marsh, Adam Langley is one of the good guys. The stuff he's talking about does exactly the opposite of what you claim it's surreptitiously doing.
  - marshray 14y ago
    Oh look, I have deep admiration for AGL. I like RMH too! I agree that they are "good guys". But this is not about the the person or the corporation. It's about the users of PKI and the massive existing code infrastructure (not just browsers) they rely upon today and the attacks to which our systems may or may not be vulnerable under the different CA issuance policies. RFC 5280: 4.2.1.10. Name Constraints: Conforming CAs MUST mark this extension as critical Sure, there are times when bending the rules of an RFC may be the right thing to do. But breaking this rule violates an interface contract critical for security, thereby retro-actively reducing the security of conformant implementations. Therefore, users and developers of existing security products must oppose this violation of RFCs.
    - tptacek 14y ago
      You keep citing the RFC as if it mattered. What matters in reality are the judgements of Microsoft, Google, Mozilla, and Apple (the HTTPS cabal). That this is annoying does not change its underlying truth. Of those four organizations, I feel like I could make a strong argument that Google is the one with the best activist stance on improving Internet privacy, the one doing the most to improve the core HTTPS infrastructure. The RFC you're citing is the product of a bunch of people sitting in a room talking. RFC policies do not bind organizations. About the most you can say about them is that they mean the HTTPS cabal is using something other than HTTPS. Ok, but that is the mother of all [sp]e[md]antic arguments. (Can we use "spemdantic" from now on?)
      - ivanr 14y ago
        The RFC may or not matter, but what does matter is doing the right thing. For example, if critical Name Constraints are not universally supported, does that make it right to use the non-critical ones? I don't think so. If Name Constraints are indeed important, I'd much rather see the CAB Forum first work with Apple until support is universal (or reasonably-well supported; whatever that means), and then start to use them.