Non-repudiation means that a certain action cannot be denied. In our case the generator, typically the content provider, cannot deny its actions. In particular we want that the server cannot deny the content it returned and the correspoding context, e.g. the previous requests by the client. Therefore, and based on previous work we introduce the notion of Non-repudiation of conversation (NRC). We define NRC as follows:
NRC provides a proof of a total order of messages sent and received by a party. Intuitively, NRC specifies the conversation and the party's role in it, from the perspective of its system. The specified party is not able to later deny a claim of having sent and received the message in the conversation or the order of messages within the conversation.
The generator provides evidence of the TLS session when requested. This evidence allows the requester to generate a proof about the TLS session. The proof can hide certain, sensitive parts of the session such as passwords, cookies or authorization tokens.
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.