Let’s explain a bit why I’m hyped about it.
There is a general assumption build into TLS by the clever people that designed it: If some Alice send something to Bob, Alice is sure that Bob can not go to another party and prove to this party that Alice said something. This is sometimes referred as deniability and was purposefully included inside TLS as a feature.
You can convince yourself with a careful reading of rfc2246 that after the handshake, any of the two party can produce the content of any transcript by using the secrets they derived. This is a desirable property in plenty of ways: for example, a web server can send redacted content to some clients and these clients won’t be able to prove to the world that the server lied. This protects TLS users on both sides in several ways and was always part of the social contract between client and servers.
The linked paper is not in a proper way a “break” of such property, but an interesting model that effectively circumvents such deniability with some applications elsewhere. They do so using some multi-party computation between a prover and a verifier, to quote the paper: « Essentially, P and V jointly act as a TLS client. […] After the handshake, P and V execute a 2PC protocol to verify MAC tags on incoming records, and to create tags for outgoing records » – the prover here is Bob in our example and commits the transcripts before the MAC keys are revealed, hence proving that the transcript is authentic and given some sound trust model around the verifier, comes from Alice.
There’s other things inside the linked paper done around the privacy of Bob, integrating this inside smart contract and other trending topics, but on my side I’m already quite happy to learn about how to circumvent TLS deniability without the web server cooperating.
TL;DR: This isn’t huge, but caught my attention as someone trying to produce web server archives whose authenticity don’t rely on the archiver’s honesty.
(the authors presented at real world crypto 2020 a couple hour ago)