TLS-N: Non-repudiation over TLS | Hacker News Reader

TLS-N: Non-repudiation over TLS

tls-n.org

81 pointsmoyix32 comments

I've been thinking about non-repudiation in TLS for archival and decentralization of public websites for a long time, but this has never been possible without modifying the server. [1] explains really well why not even non-ephemeral DH will provide evidence of transmitted data.

It's awesome this extension has been built, but it probably won't be supported by the majority of the web anytime soon. There aren't many incentives for content providers to implement this; you can probably count the ability to decentralize their infrastructure as a disincentive.

[1] https://crypto.stackexchange.com/questions/5455/does-a-trace...

Oh, this requires server modifications too? I had thought it was only client-side.

If that's the case then it makes it especially useless for the smart contract oracle use case. If you're going to have to change the server anyway, you may as well make it offer very tiny signed messages instead. You could even use secp256k1 and make it directly compatible with Bitcoin.

It's not possible to do this purely client side (how could it be? If the client can compute it on their own then they can forge it on their own), so a server/protocol modification is inevitable.

I'm think what you're saying with "offer very tiny signed messages instead" is that you think TLS is the wrong protocol layer to solve this problem at. Maybe so, but I feel like (a) that charge could be levied at TLS itself too (why not just do encryption at the application layer?) and (b) putting it into TLS means that perhaps eventually most of the web would support it.

I also wanted to draw attention to the rather clever way they allow the client to selectively redact sensitive information without losing the non-repudation property by computing a Merkle tree over the content. It's pretty neat:

> Our design is based on content extraction signatures and thereby allows the generation of non-interactive proofs based on the signed evidence provided by the generator (typically the server). During proof creation the requester can hide certain parts of the original conversation, but this will clearly visible in the proof. All the non-hidden parts are verifiable, no matter how many parts are hidden. To achieve these properties we generate commitments and aggregate them in Merkle trees for every TLS record. This allows efficient hiding of information. The hiding granularity is determined by the chunk size, which is negotiated during the TLS handshake. A smaller chunk size provides more precision while a bigger chunk size is more computationally efficient.

It's not client-side only; it requires a server component of which a possible / proof-of-concept implementation can be found here: https://github.com/tls-n/nss-tlsn

It's a modification to NSS, which isn't widely used for TLS at the server side, where OpenSSL dominates.

So, this basically has two parts as far as I can tell:

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)?

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.

Events like the LIBOR scandal make me think that this is a terrible idea.

LIBOR was easily manipulated because you could report one level and trade at another. I don't see this applying here, do you?

anyone who compromises the key can forge it

You can mitigate that risk, though, for example by requiring signed rates from many providers.

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.

TLS with Diffie-Hellman Ephemeral actually specifically works against (1)

It also sounds good to me that being able to specifically avoid (1) is also supported.

Could the decision be made as part of the choosing the cipher suite part of the handshake?

Why? And how? Could you explain that please?

(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.

> but why (2)?

Indeed! 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.

> 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.

Seems like a nice universal timestamp.

If you can mask anything then can you use XSS to get any proof you want? Doesn't even have to be code, since block chains may activate based on certain text being on the site.

The fact that something was redacted, and where, is included in the proof. So it shouldn't be a problem as long as the verifier takes this into account. A simple thing to do would be to discard any messages with unexpected readactions (e.g., create a whitelist of places where you expect redaction, such as the Cookie: header). That would prevent situations like:

    Do not give Bob $50 under any circumstances.
    Do [X] give bob $50 under any circumstances.

"TLS-N is the first TLS extension that provides non-repudiation and thereby enables parties to verify each others TLS connections and its contents."

Is it the first? X.509 client authentication provides a mutually authenticated TLS connection.

https://en.wikipedia.org/wiki/X.509

Non-repudiation != mutual authentication

Server has an issued cert. Client has an issued cert. The publics are exchanged and authenticated. Each can then be chained up to an issuer to prove identity. That's nonrepudiation.

That provides proof of identity for both parties, but not a way with which a party can prove anything about the message content afterwards. The key with which the contents are encrypted is symmetric and known to both parties, so at that state the content is not bound to the sender identity. If you can't tie content to sender identity, you do not have non-repudiation.

Reply on news.ycombinator.com