[air7]

This article really annoys me.

It's "Rage Culture" or maybe just front-page seeking by the author. The problem with that is that it makes people desensitized because if everyone is screaming all the time, one should just shut their ears. We have real issues to discuss and this isn't one of them by a long shot.

Reducing the search space from 64bits to 63bits is of no consequence because if an attack on 63bits was feasible, it would mean the same attack would work 50% of the time on 64bit (or take twice as long for 100%). That wouldn't be acceptable at all.

Sure, 64>63, but at the very least it's not "A world of hurt"

[Ajedi32]

The "world of hurt" comes from the fact that the CAs are revoking every single one of these non-compliant certs, as they're required to by the BRs.

Even though the actual security impact is nil, the current policies in place don't allow any flexibility in how non-compliant certs are treated. Therefore, millions of customers now need to replace their certificates due to a mere technicality.

[isostatic]

It isn't a problem in itself. It doesn't make the certificate any less secure in practice, even if we still used md5 as a hash.

The problem however as pointed out down-page [0] [1]

> If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly? Or internally, if you can't make sure you obey this silly rule, how are you making sure you obey these important rules?

> The reason for the urgent fixes is to promote uniformly applied rules. There are certain predefined rules that CAs need to follow, regardless of whether the individual rules help security or not. The rules say the certs that are badly formed need to be reissued in 5 days. > If these rules are not followed and no penalties are applied, then later on when other CAs make more serious mistakes they'll point to this and say "Apple and Google got to disobey the rules, so we should as well, otherwise it's favoritism to Apple and Google."

[0] https://news.ycombinator.com/item?id=19377292 [1] https://news.ycombinator.com/item?id=19375758

[fixermark]

That's a slippery slope argument, and the answer to slippery slope arguments is "We'll address serious issues with appropriate seriousness."

This specific error isn't a serious issue, as indicated by how little impact it's had on real-world security.

It's not favoritism to Apple and Google if they emit certs with 63 bits and get minor criticism and someone else, say, stops using random numbers to seed cert generation and gets raked over the coals. The latter case would require more urgent and serious attention.

[Scarblac]

It's not a slippery slope argument, it's an applying the rules argument. The rules don't allow for a difference between more and less serious infractions, they just need to be followed to the letter.

[fixermark]

"If you can't obey this silly requirement to use extra bits how can we trust you to do all the other things that we need done correctly?" is a slippery slope argument. The response is "We allocate testing resources proportionally to the seriousness of the consequences of failure to adhere to a requirement, as any good engineering project does."

It's probably worth noting that the problem lasted three years and wasn't discovered by an exploit in the wild, but by followup spot-checking of Google certs as a result of spot-checking Dark Matter certs. I don't think seriousness of the issue is in dispute.

[Scarblac]

It's saying, you have an extremely important job for the functioning of the Internet, that everybody has to blindly trust you do right.

The moment we see a small sign that you don't do it right in some detail, then that trust is gone.

Consider all the details in the spec to be Van Halen's brown M&Ms (although that had no functional effect, and losing a bit of security does). They knew that if people did that right, then they could trust that they also read the details of the rest. If Google gets this wrong, we can't trust on that.

That's not a slippery slope argument. That'd say, if we allow this then you would then do worse things because we let it go. But that's not the argument.

[geofft]

The world of hurt is not that the certificates are insecure - the world of hurt is that by the letter of the rules, which people seem intent on sticking to, millions of certs need to be revoked and replaced for (as you point out) no good reason.

And people are sticking to the letter of the rules entirely independent of the article's author. The author is not advocating for anything to be done, just reporting that this process is already in motion.

Of course we have real issues to discuss. But the fact that all these certs are going to get revoked and require replacing is a real issue that impacts people, even if there's no technical reason for it.

[fredley]

They even include the phrase "Practically speaking, there’s almost no chance of the certificates being maliciously exploited.", but continue to talk about the mistake as catastrophic. Very irresponsible.

[shawnz]

There appears to be some subtext involving a UAE state-backed CA called Dark Matter which is the real reason this is being treated so severely: https://news.ycombinator.com/item?id=19376528

[Xylakant]

Reducing the search space from 63bits to 62bits is of no consequence because if an attack on 62bits was feasible, it would mean the same attack would work 50% of the time on 63bit (or take twice as long for 100%). That wouldn't be acceptable at all.

[fixermark]

As you know, those 50%s grow quickly. But the relevant question is "How few bits before cracking the cert takes less time than the rate of reissuance?" And the answer is "Fewer than 63."

[shawnz]

I think you're missing their point. The time it takes to crack a key is given as an average. In reality, half of all 64 bit keys are crackable in the same amount of time or less than what it would take to crack a 63-bit key on average. So if they are saying that it's feasable to crack any 63-bit key in that timeframe, then it must also be true that it's feasable to crack around 50% of 64-bit keys in the same timeframe. Clearly that's still unacceptable.