On Tue, August 26, 2014 8:09 am, fhw...@gmail.com wrote: > In your rush to judgment you arrived at the wrong conclusions, Ryan.
No, I really just disagree with you. > No > problem, though, as I'll recap my points in a bit. But first: > The cert in question has as its root the utn-userfirst-hardware > certificate. That appears to be a 2048-bit cert. If the wildcard cert > should not have been issued directly under the 2048-bit root should we ask > the folks at UTN (Comodo?) to explain what happened here? Are there any > controls which are missing? Just curious how other people feel about this. Please read the Baseline Requirements Section 12. There's NO restriction about wildcard certs. > The broader purpose behind my previous email was to raise awareness within > the forum for how certain risks and vulnerabilities get combined to attack > the Internet populace. I don't think it hurts to share different > perspectives. > The salient points I hoped to get across: > * The inability to revoke endpoint certs is a major hole in Internet > security. And issuing from a root does not change this, positively or negatively. > In the case of wildcard certs the hole is that much larger > because of the damage that can be done when they get compromised. No, it's not, because it's still scoped to a domain. > Also, > having the same cert installed on multiple servers increases the risk. And both this and the former concern are concerns that has NOTHING to do with this certificate issuance, but represent your general opinions on wildcard certs. Mozilla (as do all the programs) accept and recognize both wildcard certs and name-constrained sub CAs (which are indistinguishable from wildcards), so rather than using this instance as a platform to campaign against wildcards, it would be better if you just stuck to your general concerns with wildcards. > * When an admin account is compromised a lot of things can go south, > especially if the account has access to DNS, server configs, private keys. > If the account credentials can be used in some way to issue new certs, > that can be a concern. How does this have anything to do with the matter at hand? We're talking about wildcard subscriber certs. Either way, it's an irrelevant distraction if your threat model includes "access to DNS", since by definition, they can obtain a DV cert for any domain they have access to DNS for. > * âThe scenario described is functionally similar to the NSA program > QUANTUMINSERT. If you don't have the funding nor equipment of a nation > state to back you up you might try this.For those who are interested I > would encourage you to read up on network injection as this style of > attack goes well beyond simple MITM. For starters here's a good article, > though Wired and The Intercept (and others) have good stuff too. This is, like the other points, entirely irrelevant to the conversation at hand. To put differently, what we're discussing here - a wildcard from a root - has no bearing on a discussion of QUANTUMINSERT - so it has no place in a discussion about whether or not it's acceptable to issue subscriber certs from a root. > âhttps://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ > I hope this perspective is helpful to people. I would like to know how > anyone feels about the cert issue, too. You've conflated several issues here, of varying degrees of (somewhat incompatible) threat models, but then attempted to lump them together as a concern against a particular issuance. I find that unhelpful to the extreme. If you have points to make on a specific case of issuance, you should do so. If you have general points, such as "I think QUANTUMINSERT is bad" (since you're not adding any new information to the debate/discussion), then that's best separately. I stand by the assertion that you're changing the topics and trying to lump unrelated things together in the hope that the 'badness' of one thing (QUANTUMINSERT) will somehow 'stick' to the thing you don't like (issuance of a subscriber cert from a root) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
