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