Discussion of the security properties

[cjdelisle]

Hello, I was directed here from this thread https://kosmos.social/@raucao/102678885358712290 and I wanted to verify with you my understanding:

I understand that each project has a fairly small number of code reviewers (small because they're humans in the loop and they need to make manual effort). If I understand the system properly, collusion between all of the reviewers allows false signatures to be created, which makes it possible to gaslight someone with a completely false chain.

I understand the reason for avoiding blockchain technology is to avoid turning it into a financial thing, which makes sense. But I would (assuming my understanding is correct so far) suggest that having a number of "validator nodes" who don't so any manual code review but only sign the chain, promising that it's The Chain and that they never signed any other competing chain. This can be a (say) 90 of 100 multi-sig and the signers can be operated by Known Good Guys who can be relied upon to keep a server running and secure, but obviously don't have the time or expertise to verify each different piece of software which wants to be have notarized updates.

[frankbraun]

I understand that each project has a fairly small number of code reviewers (small because they're humans in the loop and they need to make manual effort).

Yes, that's correct. You want more than one code reviewer, but it is usually not more than a few because they actually have to review the code. The main threat Codechain defends against is that a single developer is forced to push out a malicious release. Furthermore, Codechain records every reviewer signature in an unmodifiable way, delivering proof if one or more reviewers should ever collude to push out a malicious release, even to single users.

If I understand the system properly, collusion between all of the reviewers allows false signatures to be created, which makes it possible to gaslight someone with a completely false chain.

If the reviewers would do that they would create proof of that. I'll argue below why I think it is basically impossible to do a separate, malicious chain for someone in particular.

I understand the reason for avoiding blockchain technology is to avoid turning it into a financial thing, which makes sense. But I would (assuming my understanding is correct so far) suggest that having a number of "validator nodes" who don't so any manual code review but only sign the chain, promising that it's The Chain and that they never signed any other competing chain. This can be a (say) 90 of 100 multi-sig and the signers can be operated by Known Good Guys who can be relied upon to keep a server running and secure, but obviously don't have the time or expertise to verify each different piece of software which wants to be have notarized updates.

The main goal of Codechain is to allow users to automatically install and update code coming from a group of trusted reviewers. If you don't trust the reviewers then you are out of luck anyway and you have to review every code change yourself. As I said above, Codechain (with more than one reviewer) protects against a single developer being forced to sign a malicious update. You would have to force enough to reach the signature threshold.

Targeting a particular user is prevented by secpkg using DNS (ideally with DNSSEC enabled), see secure packages, as follows:

What a user needs to update his software is the current head of the hash chain which is distributed via DNS. Due to the caching nature of DNS this head is the same for everybody and it is not possible for the developers to send a different head to specific users. It is also extremely efficient, checking for updates is basically a single DNS query.

Of course there could be different mechanisms to distribute the current head in a secure way, using a blockchain being one of them. However, that would require the user to always download and verify the corresponding blockchain on his computer, which is usually very inefficient.

So I don't think using a blockchain or even "validator nodes" is the right approach here, mainly from an efficiency standpoint. I don't see how you would gain any security properties with such an approach that you don't already have with DNS.

[cjdelisle]

I did a brief talk about how this could be achieved here: https://www.youtube.com/watch?v=3cLwh7YR6Sc Basically you don't need to validate the chain, you can validate just a merkle branch going from the proof back to the bitcoin header, then verify the next 10 block headers (for example) and you know that 10 bajillion gigawatts of electricity agree that this is really the bitcoin chain, and thus the real namecoin chain, and thus you're not being fooled. The really cool thing about it is you don't even need internet access, the provider of the software update can send you the proof along with it.

[JonathanLogan]

I think the option of going through a blockchain is unnecessary as well. There are two scenarios here:

• Developers+Reviewers creating a "bad" second chain.
• Delivering that chain to a specific user.

As frankbraun mentioned, creating a bad chain also creates proof of a bad chain. In that case the software in question shouldn't be used by anybody ever again. It is a breakdown of the trust in the review process itself, no technology can prevent that, only make it visible.

For delivering a chain to a specific user you'd have to be able to KNOW which request for the current head is issued by that user. DNS (with DNSSec) would require both the DNS resolver operator(s) and the controllers of the DNSSec keys to collude. This is a complex attack scenario already - though not impossible.

Using a blockchain to validate the same issue is actually about delivering a proof of uniqueness. This requires that all the proofs generated for a valid head are exclusionary. The approach there would be to use verifiable datastructures (Merkle trees with the path being the same as some constant that refers to the project). This is what Certificate Log does, except that it doesn't need a proof-of-X blockchain for that but only signing auditors.

The more abstract proof here is the "everybody has the same code" approach. This breaks down to gossiping the chain from some globally agreed on entry to the current head. Codechain would make that approach really easy, but, it is not necessary because easier ways of hardening are possible.

The easiest approach is to just send a lot of DNS head requests through a lot of secure DNS servers. So, for example, one could easily exhaust the DNS-Crypt's collection of servers automatically, sending the head request through all. A collusion between all those parties and the developers/reviewers is more than unlikely. A single request that would point to a different chain would immediately trigger that something fishy is going on.

Comparing the complexity required between blockchain, fanning out many DNS requests, and verifiable datastructures clearly points at DNS being much easier, lower complexity, lower potential errors, and less dependencies.Oh, and no.... the bitcoin blockchain is probably a really bad

DNS is there, it works, and it wont go away anytime soon. DNS Crypt with the host of available servers there makes it a large enough pool to get realistically trustable sets of resolvers without leaking to the ISP, or manipulation by the ISP.

I strongly opt for whatever solution has LESS code - less stuff to review, less corner cases. That's DNS.

[frankbraun]

This discussion is rather old, I'm closing it. Please reopen if necessary.