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