Live data from Hacker News

Avoiding Internet Centralization

mnot.github.io

1–10 of 111 posts

Re: Avoiding Internet Centralization

#2
> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ...

The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on certificate authorities. And CAs are always highly centralized and highly centralizing.

If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet. There's an easy solution to this though. Don't throw alway plain protocls. Plain and TLS wrapped are synergistic. Use both. There's no need for, and it is damaging, to always encrypt without an option for plain text.

A hypothetical downgrade attack is not an excuse for using only highly centralized TLS CA based protocols in this context.

Re: Avoiding Internet Centralization

#3
> Some protocols require the introduction of centralization risk that is unavoidable by nature. For example, when there is a need a single, globally coordinated 'source of truth', that facility is by nature centralized.

No, there is nothing unavoidable in making a centralized DNS system.

Re: Avoiding Internet Centralization

#4
post #3

> Some protocols require the introduction of centralization risk that is unavoidable by nature. For example, when there is a need a single, globally coordinated 'source of truth', that facility is by nature centralized. No, there is nothing unavoidable in making a centralized DNS system.

You convert a single point of truth to a set of the point of truth and a voting system. The current cryptographically signed model uses a single signing authority. I suppose you could argue for multiple independent signing but it begs the question how you arrived at what was to be signed. That's a process to a unitary decision.

Re: Avoiding Internet Centralization

#5
A recent example is "Message Layer Security".

While Wire and Matrix are working on a decentralized version the IETF is, unfortunately, working towards one based on a central entity.

Source:

https://news.ycombinator.com/item?id=25102916

https://matrix.org/blog/2021/06/25/this-week-in-matrix-2021-...

Re: Avoiding Internet Centralization

#6
post #2

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on cert…

Encryption does not imply authentication, does it?

Re: Avoiding Internet Centralization

#7
post #6
post #2

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on cert…

Encryption does not imply authentication, does it?

Browsers scaremonger really hard about self-signed SSL certs. And browsers are starting to implement HTTPS only as a default. It won't be too long before HTTP is blocked by mega-corp browsers and not having a CA TLS cert means your website is now un-visitable by non-technical people (and not indexed by search engines).

Re: Avoiding Internet Centralization

#8
post #3

> Some protocols require the introduction of centralization risk that is unavoidable by nature. For example, when there is a need a single, globally coordinated 'source of truth', that facility is by nature centralized. No, there is nothing unavoidable in making a centralized DNS system.

Right. Even putting aside blockchain-based systems, you can have systems without a dictator because they're based on voting.

Suppose the root is a set of public keys, each with a top level domain. Adding one requires a supermajority of the others to agree. Removing one is impossible; it can sign its own successor and that's it. You now have a federated system with no single chokepoint.

Re: Avoiding Internet Centralization

#9
post #2

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on cert…

> This is because the current status quo for encryption is to use TLS based on certificate authorities.

Not everything has to be TLS or even HTTP. Look at messaging apps. Signal is encrypted, but the end-to-end encryption it uses isn't TLS and doesn't use certificate authorities.

> If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet.

Not really. Let's Encrypt doesn't have a monopoly over anything. They use an open protocol (ACME) that any other CA could implement. If they went evil, someone else would implement the same protocol and everybody would switch to them. Which also implies that they won't, because why bother if that's what will happen?

This is kind of a problem with the CA system the other way -- if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about.

Post reply on HN