If I understand it correctly, (2) is to move data with evidence of its source into the blockchain so smart contracts can use it. E.g. if a contract is supposed to be tied to the value of the dollar, it could require exchange rates from a list of API providers as "evidence", and people submitting this evidence could use TLS-N to prove that they are submitting data that came from these providers and are not making numbers up.
Events like the LIBOR scandal make me think that this is a terrible idea.
Not to mention that this is nowhere near proving that an exchange thought that whatever instrument closed at whatever price -- anyone who compromises the key can forge it. We all know that TLS keys are totally secure, though, so it's no big deal.
If I remember LIBOR correctly, it also had multiple sources of information colluding to influence an "algorithm" that worked based on their claims, whose output in turn was used in other contracts a source of "truth" (which apparently now has caused some issues with changing it, since long-running contracts reference it as such). That seems quite similar.
Right, but as far as I understand it, the problem is that the reported LIBOR and the actual LIBOR could differ, and they could arbitrage that different. I don't think that applies here.
The alleged goal was to make a smart contract that depended on something outside the blockchain by using TLS-N. The LIBOR scandal was an example of a bunch of data sources colluding to lie to manipulate LIBOR. The data sources in this TLS-N scheme could collude to deceive the smart contract.
I don't think so, because these data sources are the exchanges were people trade currencies, and if the numbers sent were significantly different from the rates at people were actually trading, they could be easily caught.
Plus, it's not clear that they have any way of knowing that a certain API call fetching the rates is going to a particular smart contract, so they'd have to lie to everybody in a way that is immediately apparent.
In that case, look at the forex fixing scandal for inspiration. The exchanges reported entirely correct data -- the problem was that banks (allegedly) executed intentionally bogus deals because that only cost a bit of money in comparison to the large amounts of money that they made as a result of manipulating the reported data.
Oh, cool! I had been under the mistaken assumption that tls already supported (1), and was disappointed to learn that this was not the case, so something that adds support for that sounds great to me.
(2) allows smart contracts to securely get input from the outside world. So for example you can have a smart contract make decisions based on stock prices.
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.
> 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.
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/
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.
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?).
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.
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.
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.
1. "signing" the contents of a TLS session (proving that they happened)
2. putting this on the blockchain
I can kind of see the utility of (1), but why (2)?