Hacker News Reader

Comment by tptacek | Hacker News Reader

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?)

View on HN

Oh, I hold no illusion of the infallability of the IETF process!

But at the end of the day the world needs to have secure SSL/TLS applications. This requires it to be possible for "one skilled in the art" to be able to design and implement an application using this protocol. He must be able to understand the stated and implied requirements for security in order to have any chance of producing a secure application. And a secure application needs not just to interoperate well, but it must also refuse to interoperate insecurely, prevent impersonation, and so on.

So if we can't end up with secure applications by writing them to the RFCs, then what the hell do we write them to?

Where is this document defining all the ways in which CAs now and in the future feel free to relax the identity constraints which rely upon them to provide?

If it is not possible for a competent and conscientious software developer to write a client application from existing documentation, rely upon a set of root CAs, and end up with a countably finite and well-bounded number of private keys in existence that can impersonate legitimate servers to his application then the CA system has failed in its one and only mission.

The point is that writing them to the RFC would not make them secure. The alternative to non-critical nameConstraints is no nameConstraints, which is RFC-acceptable. You're just wrong here, Marsh.

No, the alternative is no more fucking 3rd party sub-CAs under widely trusted roots.

You've fallen for the old switcheroo.

Groan. Nobody gets to do anything to make HTTPS more secure until the world conforms to our norms?

Selling widely-trusted sub-CAs to 3rd parties, with or without name constraints, does absolutely nothing to make HTTPS more secure for me or the vast majority of relying users.

Nevertheless, if you want to sell sub-CAs with critical name constraints to 3rd parties from your widely-trusted root, fine. That's been a defined feature of PKI for a long time.

If you want to sell sub-CAs with noncritical name constraints to 3rd parties, that's fine too. Just do it from a different set of roots than the ones that we all agreed to rely upon, precisely because we had our expectations set that they would not do that sort of thing.

Who's "we"? The people who need to agree about this --- the HTTPS cabal --- have already accepted non-critical name constraints. If you disagree with them, remove GlobalTrust from your CA store.

"We" are consumers who rely upon HTTPS to protect our $50 liability limited credit card transactions.

"We" are citizens living in repressive regimes who rely upon HTTPS to protect our emails arranging our family's emigration and escape from persecution.

"We" are software developers relying on HTTPS to secure our connections to Github to prevent attackers from inserting backdoors in our codebase.

"We" are the servers who rely upon the HTTPS client to do a thorough job of proving the absence of an active attacker on the network between us.

"We" are the relying parties.

That's a rousing speech, but, again, and to a first approximation, there's only 4 organizations in the world who need to agree on TLS PKI policy. You work for one of them, don't you? Go yell at them.

Yeah I didn't mean for it to sound all rousing like that, it just came out that way.

You're probably correct in that "4 organizations in the world need to agree on TLS PKI policy", but that doesn't make it a good thing. The problem is that these N ~= 4 organizations tend to not see themselves as directly bearing the risk of a security failure in the trusted root program. The true Relying Parties are greatly underrepresented in this discussion.

I see people from many of these orgs here in this HN discussion. And, yeah, you can count on some folks getting an earful as soon as the occasion arises.

For anyone coming to RSA 2013 San Fransisco we'll be having an SSL/TLS panel discussion. This topic seems likely to come up.

I of course feel a little singled out here but as has been called out by Adam many (if not all) trusted roots have this same offering.

It is allowed by all the root programs.

The practices (both technological and procedural) we put around our program are some of the best in the industry, we take this responsibility very seriously.

More over we very rarely do it and instead work with customers to utilize our managed PKI offerings where we operate the infrastructure on behalf of the customer.

many (if not all) trusted roots have this same offering

Really? Care to name names?

If this is so common, allowed, and totally above-board, why is the industry being so secretive about it?

Why won't the CA industry disclose even the number of sub-CA (constrained critically, noncritically, or not at all) private keys in possession of 3rd parties (HSMs or no)?

Just look at the root program members in the Mozilla program, look at EFF data or the great notary.icsi.berkeley.edu/trust-tree/

As for disclosing all CAs have agreed to disclose -- no secret here at all.

And clearly from this thread I am being very open :)

Those projects show sub-CAs actually seen in public scans. They don't show all the sub-CA certs that could be used to compromise one's own security. We don't even have any idea what percentage of sub-CAs they show. For example, I doubt they show the TURKTRUST sub-CA that was used in an actual MitM of Google (and likely many others).

This is not directed specifically at you @rmhrisk, but it's really disappointing how everyone involved in PKI seems to have a systematic habit of pretending like clearly identified potential risks and vulnerabilities are equivalent to impossible until (and sometimes even after) they're actually caught being used in an actual exploit.

Marsh, I understand your concern and I share it though I don't agree with the conclusion (re sticking head in the ground).

With that said GlobalSign has committed to implementing CT and we hope all other CAs agree to do the same as Adam points out earlier in this thread its the way to bring the desired transperancy.

That said it alone inst enough either, to start we also need TACK (and/or HSTS pinning), CAA, robust revocation checking and Name Constraints.

And while conversations like this are uncomfortable (certainly for me being on the receiving end) I think they help too.

So are you proposing that 3rd party sub-CAs be brought under public CT?

I could get on board with that.

I believe for CT to "work" all CAs on the public internet need to participate.

I also believe that certificate transparency by itself is insufficient and the other items I mentioned are also needed.

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.

Careful: two different arguments here. One is what Google is doing, the other is what GlobalTrust is doing.

While I'm not alarmed by what GlobalTrust is doing, I think CA's should not be in the business of selling CA=YES certificates to other organizations. No matter what X.509 allows them to express.

Reply on news.ycombinator.com