CA alternatives [mysterious magical discussion]

[sugarpuff]

Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? After all, when I visit a website, the "other end" is the website's server. It must always have the ability read the cleartext, and thus your second point is IMHO something which simply can't be avoided with any system. How would it be different if we used another encryption system?

In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).

[sugarpuff]

I'm primarily concerned with communication between humans, we've not yet reached the point where we have to protect sentient machines.

[virtual_master]

The problem is not one of encryption but of authentication. Once you have authenticated the other side you can set up a secure encrypted channel with PFS.

A compromised CA enables a MITM to authenticate himself as the target domain, and thereby break into the communication. The only way around this is to get rid of CAs.

A slightly better alternative to CAs is DANE/DNSSEC. The problem here is, of course, that you have to trust the DNS root keys, your TLD's keys and your own DNS operator...

Yes but this is not a .bit domain specific problem.
As far as I understood exactly this is intended to be solved by Biolizard's convergence. I am not sure how far is this working at the moment but it shouldn't require any centralized CA only self signed certificates where the TLS fingerprints are stored in the blockchain.
The Namecoin blockchain could provide decentralized certificate authority even for non .bit domains.
However it depends of the browser abilities to support it and the domain owners willingness to implement it.
Surely this is a server - user communication because the webpage content is provided to many users.

In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).

If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.

However I was thinking about how could Namecoin prevent such attacks.
What about embedding in the domain entry additionally to the TLS fingerprint a content GPG public key, where the corresponding private key wouldn't be on the server but by the person who is redacting the content. Every time the content deliverer is actualizing the content needs to put to a specific place (for ex in the html header in a special tag) the content signature.
The browser (with a special plugin or special browser) would check the content signature against the content and the public key (in the Namecoin blockchain) and could authenticate with 100% security that it comes from the author.
Content hijacking would be never ever possible on the world.
Here would be a content editor - user authentication which would be much secure then server-user authentication. (encryption would remain on server-user, there is no other possibility for unidentified and unregistered users)

[sugarpuff]

In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).

If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.

I am not talking about p2p communication specifically, but rather communication in general, whether it's p2p, or a server-client situation. I was also not referring to the content that the server delivers (in the sense of web pages), but rather I was focusing on the communication that servers route between users.

Namecoin + DNS can fix this, which is the project that I'm working on. I hope to post more details soon.

Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:

http://dot-bit.org/forum/viewtopic.php?f=5&t=1163

In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.

Storing fingerprints of the public key is totally cool though (and something I'll be relying on).

[virtual_master]

Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:

http://dot-bit.org/forum/viewtopic.php?f=5&t=1163

That thread is generally about the size of the value field.
The GPG addressed there was related to the ID. Here I brought a new idea to store the GPG in the domain entry to secure the content and was not related to the value field size.

In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.

Storing fingerprints of the public key is totally cool though (and something I'll be relying on).

Your argumentation was based on the worry about the blockchain size in a couple of generations which will be not a problem as I demonstrated.
Namecoin have to solve the issues facing now and not that far in time. If we don't solve the actual problems then there will be no Namecoin in 60 years.
Of course could be stored for every entry only the hash of all but then why we need Namecoin ? The hash can be stored in 80 bits also on the Bitcoin chain. Even this is to much. You need to make a Merkle tree and to store only the root hash and update it. As more complicated you make it as more difficult will be to implement it.

But if you can present a really good solution I am ready to change my mind.

[domob]

1. 3. HTTPS + PFS does not (I don't think) protect against active MITM attacks involving compromised CA certs.

End-to-end encryption, therefore, is the only reliable solution, and HTTPS does not offer that.

Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? How would it be different if we used another encryption system?

The problem is not one of encryption but of authentication. Once you have authenticated the other side you can set up a secure encrypted channel with PFS.

A compromised CA enables a MITM to authenticate himself as the target domain, and thereby break into the communication. The only way around this is to get rid of CAs.

A slightly better alternative to CAs is DANE/DNSSEC. The problem here is, of course, that you have to trust the DNS root keys, your TLD's keys and your own DNS operator...

Of course, but the CAs actually are eliminated if you use TLS with Namecoin (like Convergence for Namecoin is doing). So that's not the question here.

[biolizard89]

In many cases, and especially the situations I'm looking at, the "other end" is not the server. The other end is an individual (or group of individuals). In such cases only these individuals should have access to the cleartext, and the server should just act as a relay between them (optionally storing the ciphertext).

If you want to use p2p communication then you can use torchat but .bit domains are intended primary to deliver content from server to user so it can be used only a server-user level encryption.
I am not sure but may be are you meaning that the user even if he was redirected from the domain name to the right IP he cannot be sure that the server with the content was not hijacked.
This is again not a Namecoin specific problem.

I am not talking about p2p communication specifically, but rather communication in general, whether it's p2p, or a server-client situation. I was also not referring to the content that the server delivers (in the sense of web pages), but rather I was focusing on the communication that servers route between users.

Namecoin + DNS can fix this, which is the project that I'm working on. I hope to post more details soon.

Regarding storing GPG keys in the keychain, there's a discussion about that in this thread:

http://dot-bit.org/forum/viewtopic.php?f=5&t=1163

In there I object on the grounds that storing the entire key is not necessary, and that it would bloat the blockchain for no good reason, which would have an impact on bringing new DNS servers and other NMC clients online.

Storing fingerprints of the public key is totally cool though (and something I'll be relying on).

If you don't trust the HTTP server (and of course you shouldn't), wouldn't something like the WebPG extension be sufficient? https://webpg.org/ Probably wouldn't be hard to get it to work with Namecoin....

Using the Namecoin blockchain to sign web pages sounds kind of cool too. The proposed hash/ namespace could be used to sign individual resources, and a field in the d/ namespace could be used to specify which keys are authorized to sign via hash/. Just thinking out loud here....

[sugarpuff]

If you don't trust the HTTP server (and of course you shouldn't), wouldn't something like the WebPG extension be sufficient? https://webpg.org/ Probably wouldn't be hard to get it to work with Namecoin....

Sufficient to do what, precisely?

Using the Namecoin blockchain to sign web pages sounds kind of cool too. The proposed hash/ namespace could be used to sign individual resources, and a field in the d/ namespace could be used to specify which keys are authorized to sign via hash/. Just thinking out loud here....

Maybe I'm misunderstanding something... or are you actually suggesting storing a hash of every webpage on the internet in the blockchain?!?

[sugarpuff]

Mystery no more: https://dot-bit.org/forum/viewtopic.php?f=5&t=1423

[Pagel1928]

Even if they all supported HTTPS with PFS, it wouldn't matter! Why? Because PFS only protects the data whilst enroute to the server (and away from it). Once it reaches the server, the security is completely undermined because companies will store it in the clear in their databases (or encrypted, but the companies hold the keys, which effectively amounts to plain-text).

Just to point out, the reason you use perfect forward secrecy, is so if an attacker is recording all the encrypted communication, they will be unable to decrypt it if they manage to get the private key stored on the server.

Your argument is the same as the fact the server could be recording the ephemeral keys.