6

I understand that SSL/TLS provides confidentiality and integrity.

But does it provide non-repudiation? I read in one book it does not. But I wonder why? What does it mean?

  • If it means Alice can repudiate she holds that public-key? Then, TLS supports non-repudiation as the public-key of the website is digitally signed by a Certificate Authority.
  • The other possibility is that the book means Alice can repudiate she sent these messages?

Can you clarify this point please, preferably with references.

1

2 Answers 2

17

Update 2017-11-05: "TLS-N" and others

I only recently learned of the existence of a new project. Some guys from the university of Zürich are working on something called "TLS-N" which is dedicated to bringing non-repudiation to TLS. There is no RFC that I know of yet. But they have a white paper. I'm not sure when/if we'll ever see this in the wild. But it's an interesting idea. See: https://tls-n.org

Also mentioned in their paper are some earlier attempts at bringing non-repudiation to TLS called TLS sign and TLS Evidence. Both attempts seem to have died a long time ago.

Your book is right. There is no non-repudiation for regular TLS packets.

When Alice tells Bob "Let's kill the president!" and Bob goes to tell the police, then Alice can always say: "I never said that." So Alice just repudiated the previous statement.

And in regular TLS there is no way for Bob to prove by himself that Alice has in fact repudiated her earlier statement.

So no, regular TLS does NOT provide non-repudiation. So your book was right.

Signatures can provide non-repudiation...

Now why is that? Asymmetric crypto allows you to provide proof of authorship by using Cryptographic Signatures. This WOULD in fact give non-repudiation. Then it would be straight forward to verify Yep, that really WAS signed with Alice's private key. And there is no getting out of that mathematic fact. (Of course then Alice could say: "But my key was stolen!" but there's no denying that her key was used to sign that particular message.)

So if in fact crypto signatures were used for regular TLS packets then they would be non-repudiatable. But signatures are NOT used for the regular TLS packet, so we don't have non-repudiation either.

...but TLS packets are MACed instead

Instead what is used to prove to the other side, My message has NOT been changed along the way is something called a MAC, a Message Authentication Code. MAC-functions work like this: You drop in two inputs and you get one output. One input is a secret MAC-key, the other input is the message that you want to protect. And what falls out is like a two-dozen byte hex-string, called a MAC Value. That string is sent along with the encrypted message. The recipient then feeds the same to inputs into the MAC function again and only accepts the decoded message if the MAC Value matches.

But since Alice and Bob both know the secret-MAC-key either one of them can generate MAC-values for whatever message they like. A MACed message says NOTHING about authorship of either Alice or Bob.

So if Bob goes and tells Charlie: Here's something evil Alice said!, then Alice can rightfully say: You could have written that your self!.

And thus: No non-repuditiation.

Alice beware

But: If there is a trusted third party (Alice's employer Charlie maybe) that has a network dump of the entire conversation between Alice and Bob then Alice will be in trouble. Regardless of any non-repudiation properties of TLS. Because Charlie vouches for the authenticity of the original network dump and Bob provides the key to decrypt the conversation. Of course Alice could still say Charlie is in on this! I'm being framed! but she's basically lost then.

7
  • 1
    @jas- perhaps all these comments could be cut short if you explained how OCSP provides non-repudiation. Could you also confirm that non-repudiation is available in both directions (server and client) or not?
    – schroeder
    Oct 25, 2015 at 16:00
  • 1
    @jas- I don't get it. How is a revocation mechanism going to give non-repudiation? And of what? Oct 26, 2015 at 10:06
  • @jas- agreed. So? How is that related? Oct 26, 2015 at 10:49
  • @jas-: Okay. So the owner of the pubkey/cert is known to ALSO have had the privkey at some point. Is that what you're saying? Oct 26, 2015 at 11:39
  • See crypto.stackexchange.com/questions/5455/… for more information on why TLS/SSL (alone) cannot be used to prove that a server sent a particular message to a client.
    – mti2935
    Feb 23, 2016 at 15:56
0

TLS does not provide non-repudiation.

TLS is a transport layer protocol, that helps to protect the data that flows from one point to another. You can authenticate hosts with certificates or even a user with a client certificate.

However, non-repudiation means you can prove that a specific person received a message or is the author of a message. This always involves some kind of digital signature, which that person has to create using a secret (password, or key).

You can create such a digital signature with the same certificates you use for TLS authentication, but TLS itself does not provide any means for realizing non-repudiation of messages.

You could loosly say that non-repudiation is a layer 8 protocol somehow, where a person has to interact in order to prove that they read or authored something.

2
  • @jas: the signature in a properly-issued certificate, plus revocation checking, proves the identity of the server which is authentication, but it does not provide evidence the server sent any particular data and thus does not provide nonrepudiation. Also PKCS7 and PKCS12 contain certificates but do not provide any information about their structure, and PKCS11 doesn't involve certificates at all. Jun 27, 2018 at 7:56
  • The idea is: if the network packets were enough to prove to my browser that site's authorized server yielded data at date, then why couldn't that sequence of packets be stored and used to prove the same to an arbitrary observer at a later date? May 13, 2020 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .