4 ms·

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 contrac

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.

Confiks 9y ago
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 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.
moyix 9y ago
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.

Confiks 9y ago

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

moyix 9y ago

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.