4 ms·

> but why (2)? Indeed! https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... Not

> but why (2)? Indeed! https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc... Not everything needs a blockchain. We already have Certificate Transparency, which is the closest to a blockchain-esque solution that adds value to the TLS/PKI infrastructure. Adding non-repudiation to TLS just seems like a privacy foot-cannon. Using a "blockchain" to solve this just smells fishy.

floatboth 9y ago
> Adding non-repudiation to TLS just seems like a privacy foot-cannon. Well, not everything needs to be private! :) e.g. the contents of news articles and such — the "Trustworthy Web Archive" use case sounds great: nytimes.com serves an article with TLS-N, web.archive.org downloads it and stores the proof, you can access the archived copy and verify that it's authentic. Actually, Certificate Transparency might help with checking that the TLS certificate the proof was made with actually belonged to nytimes.com.
- dvanduzer 9y ago
  The use case of a verifiable archive would be better handled if example.com simply published content checksums for every URL out of band. Van Jacobson worked on a system based on this concept at PARC about 10 years ago, and it has since evolved into the NDN protocol: https://named-data.net/project/execsummary/ https://named-data.net/project/execsummary/ Putting this into TLS is absolutely a privacy foot-cannon, simply because it is used so widely in one-to-one communication that (most parties) agree should be completely private. That said, it seems like it would be relatively easy to guard against abuse of the feature, as long as clients implementations err on the side of only adding non-repudiation to an exchange when absolutely required.
  - moyix 9y ago
    How does that get you non-repudiation? If (e.g.) the NYT decides they want to change the content later, couldn't they just change the content checksum as well? Maybe by checksum you mean a digital signature? I think I'm still not clear on how non-repudiation harms privacy even in 1-1 communications. Clients in such situations can already elect to disclose the contents of the communication later; this just gives them the ability to do so in a way that makes it harder for the other party to claim it never happened (and if this is your goal, why aren't you using something that explicitly provides deniability like OTR?).
    - dvanduzer 9y ago
      You are correct. I was writing sloppily, and I should have referenced cryptographically secure content hashes. (And ideally published in a public, append-only fashion.) The key difference being whether you are validating the content, or the specific instance of the retrieval of the content by one other party. As far as the top of this thread is concerned, I'm advocating only (2) and never (1) for the "validating archives" purpose. Consider a spectrum between "secure but trivial to repudiate" and "secure but nigh-impossible to repudiate with OTR and TLS-N on each end. Most secure messages are passed in situations somewhere in the murky middle. A privacy purist might argue that OTR-like behavior should be the default full-stop. The question of "harming privacy" in any situation is more like spacecraft engineering than software engineering. We really do need to care about the very low probability events, because the cost of failure can be catastrophic to the individuals involved. Just pragmatically speaking, 1-1 communication in the context of TLS frequently means individual humans interacting with individual business/legal entities. Sure, the intent of anyone publishing a post on reddit is one-to-many communication. But privacy in reading such a thing is a relatively new problem. It used to be a 1-1 relationship between you and the kid selling newspapers on the corner of town square. Even in the age of television, it was still a reasonable expectation that CBS didn't know and couldn't prove you were watching Walter Kronkite.
detaro 9y ago
It doesn't add a blockchain to TLS. It describes a TLS extension, and how you can use said extension to do something people in the blockchain space have asked for.
AgentME 9y ago
There are already people wanting to do #2 (use verified data in blockchains), and this system is the answer to that problem. This system isn't tacking on blockchains to solve some other problem; this system is built partly to solve a problem encountered by people already using blockchains.

floatboth 9y ago

> Adding non-repudiation to TLS just seems like a privacy foot-cannon. Well, not everything needs to be private! :) e.g. the contents of news articles and such — the "Trustworthy Web Archive" use case sounds great: nytimes.com serves an article with TLS-N, web.archive.org downloads it and stores the proof, you can access the archived copy and verify that it's authentic. Actually, Certificate Transparency might help with checking that the TLS certificate the proof was made with actually belonged to nytimes.com.

dvanduzer 9y ago
The use case of a verifiable archive would be better handled if example.com simply published content checksums for every URL out of band. Van Jacobson worked on a system based on this concept at PARC about 10 years ago, and it has since evolved into the NDN protocol: https://named-data.net/project/execsummary/ https://named-data.net/project/execsummary/ Putting this into TLS is absolutely a privacy foot-cannon, simply because it is used so widely in one-to-one communication that (most parties) agree should be completely private. That said, it seems like it would be relatively easy to guard against abuse of the feature, as long as clients implementations err on the side of only adding non-repudiation to an exchange when absolutely required.
- moyix 9y ago
  How does that get you non-repudiation? If (e.g.) the NYT decides they want to change the content later, couldn't they just change the content checksum as well? Maybe by checksum you mean a digital signature? I think I'm still not clear on how non-repudiation harms privacy even in 1-1 communications. Clients in such situations can already elect to disclose the contents of the communication later; this just gives them the ability to do so in a way that makes it harder for the other party to claim it never happened (and if this is your goal, why aren't you using something that explicitly provides deniability like OTR?).
  - dvanduzer 9y ago
    You are correct. I was writing sloppily, and I should have referenced cryptographically secure content hashes. (And ideally published in a public, append-only fashion.) The key difference being whether you are validating the content, or the specific instance of the retrieval of the content by one other party. As far as the top of this thread is concerned, I'm advocating only (2) and never (1) for the "validating archives" purpose. Consider a spectrum between "secure but trivial to repudiate" and "secure but nigh-impossible to repudiate with OTR and TLS-N on each end. Most secure messages are passed in situations somewhere in the murky middle. A privacy purist might argue that OTR-like behavior should be the default full-stop. The question of "harming privacy" in any situation is more like spacecraft engineering than software engineering. We really do need to care about the very low probability events, because the cost of failure can be catastrophic to the individuals involved. Just pragmatically speaking, 1-1 communication in the context of TLS frequently means individual humans interacting with individual business/legal entities. Sure, the intent of anyone publishing a post on reddit is one-to-many communication. But privacy in reading such a thing is a relatively new problem. It used to be a 1-1 relationship between you and the kid selling newspapers on the corner of town square. Even in the age of television, it was still a reasonable expectation that CBS didn't know and couldn't prove you were watching Walter Kronkite.

detaro 9y ago

It doesn't add a blockchain to TLS. It describes a TLS extension, and how you can use said extension to do something people in the blockchain space have asked for.

AgentME 9y ago

There are already people wanting to do #2 (use verified data in blockchains), and this system is the answer to that problem. This system isn't tacking on blockchains to solve some other problem; this system is built partly to solve a problem encountered by people already using blockchains.