Rate limiting frequency would need to be one mitigation for sure, doesn’t address the complexity of authorization verification, especially when looking at their supposed SLA goals of a hours to days turn around.
-
-
Consider the efficacy of EV verification today (woefully insufficient even for use) as the best case and this is much harder because it’s a authorization not authentication verification that needs to take place.
1 reply 0 retweets 0 likes -
Replying to @rmhrisk @carrickdb and
Right, but you believe build infra and package signing to be good enough today. It seems unreasonable to say it has to be more secure than that, otherwise it seems like an idealogical objection rather than a technical one (which is fine too, but you said that's not the reason).
1 reply 0 retweets 0 likes -
Replying to @taviso @carrickdb and
Today bootloaders ans OS files are signed by a limited set of authorized people within the company creating the offering. Not got arbitrary third parties across the globe, those individuals identity, affiliation and entitlement must be verified; this is new.
1 reply 0 retweets 0 likes -
Replying to @rmhrisk @carrickdb and
That's only partially true, but even if we accept it for discussion, they still just grab those blobs from the build infra, right?
1 reply 0 retweets 0 likes -
Replying to @taviso @carrickdb and
At Microsoft, for example, a quorum of people authorized as signer in the organization that kicked off the build must approve the signing. Only a limited set of people can merge into master, and a much smaller subset approve signing with prod keys.
1 reply 0 retweets 1 like -
You would not, for example, get those in the defined quorum to approve a package to be signed with prod keys if no release was scheduled/planned. Things like bootloaders for firmware are often done with manual processes and entirely offline.
1 reply 0 retweets 0 likes -
As I conceded before it’s certainly possible for an attacker to insert malicious code into source control, especially something minor that would be missed. That could get signed in such a case if the attacker was patient enough.
2 replies 0 retweets 0 likes -
Replying to @rmhrisk @carrickdb and
Okay, and if key escrow matched this level of risk, you would agree it's not a significant increase in attack surface? With the understanding that you believe law enforcement would want more frequency and scale that this could provide.
1 reply 0 retweets 0 likes -
Replying to @taviso @carrickdb and
Nope :) making a failure mode a healthy path has additional risks. For example the authentication, authorization and frequency changes.
1 reply 0 retweets 0 likes
Okay, I think we just disagree then
I think the current infrastructure is less secure than you think, which weakens the argument that key escrow must meet an imagined bar... It's still an okay argument though.
-
-
Replying to @taviso @carrickdb and
I think we’re closer than you think. The main difference I see is that you trivialize the impact and complexity of operationalizing a security vulnerability.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.