Question

So, a few questions:

1) Does using a client certificate during TLS provide non-repudation?

1a) Follow-up: If so, does having a load balancer handle the transaction still provide this assurance at the end server/service level?

2/2a) Same questions as above, but for message integrity.

I know the answers for MLS, but I’m not sure about TLS. If I understand correctly, TLS involves a handshake where the shared secret is established, and that is used to secure the pipe – so none of these things hold, since each message uses only the shared secret.

Answer 1

1. Does using a client certificate during TLS provide non-repudation?

1a) Follow-up: If so, does having a load balancer handle the
transaction still provide this assurance at the end server/service
level?

TLS is about transport level security (hence the name Transport Layer Security). It aims to secure the communication between the client and the server (possible a load-balancer), according to the specification:

The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications.

You could in principle keep the entire TLS exchange, in particular keeping the handshake to prove that the client-certificate signed the content of the Certificate Verify message. You would also have to keep the various generated/calculated intermediate values (in particular the master secret, and subsequently the shared key). There is one problem with this: the TLS specification requires (only with "should") the pre-master secret to be deleted. This could make proving the path back from data to client certificate rather difficult. (You would certainly have to tweak SSL/TLS stacks to record all this too.)

In addition, recording all this would be under the application protocol (assuming HTTPS here, but the same would apply to other protocols). This would certainly be another layer before you get to the actual data you want not to be repudiated. (The problem is that you may have to record the entire session for proof, without being able to select with request/response to isolate.)

You may also run into further problems when it comes to session resumption (for example) and generally parallel requests. This would certainly add to the confusion.

Overall, it’s not what TLS is designed for. Non-repudiation is about being able to keep a proof of the exchange, possibly to be able to display it in court or similar. Explaining to people (who might not have the technical background) how you make the link between the interesting data and the client certificate could be challenging.

2/2a) Same questions as above, but for message integrity.

TLS guarantees the integrity of the communication (see introduction to the specification). (All of this, of course, provided that the client verifies the server certificate correctly, although you should be able to detect a MITM if you’re using client certificates anyway.)

Integrity will only be guaranteed up to the point where the TLS connection ends. This will be the load-balancer itself if you’re using one. (Of course, it’s better to link the load-balancer to its worker nodes via a network that can be trusted.)

If you’re after a system where clients can send non-repudiating messages, which can be audited at a later date, you should look into message level solutions.