
TLS-N: Non-repudiation over TLS - moyix
https://tls-n.org/
======
Confiks
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...](https://crypto.stackexchange.com/questions/5455/does-a-trace-of-ssl-
packets-provide-a-proof-of-data-authenticity/5467#5467)

~~~
TD-Linux
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.

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

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

~~~
CiPHPerCoder
> but why (2)?

Indeed! [https://tonyarcieri.com/on-the-dangers-of-a-blockchain-
monoc...](https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoculture)

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.

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

~~~
dvanduzer
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/](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.

~~~
moyix
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?).

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

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

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

------
patcheudor
"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](https://en.wikipedia.org/wiki/X.509)

~~~
floatboth
Non-repudiation != mutual authentication

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

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

