5

TLS Sign was proposed as an IETF Draft in June 2007.

I have not found further information, besides that the draft expired in November 2007. Can someone tell me what happened with this extension or can someone point me to an extension, or a mechanism that provides non-repudiation for TLS connections.

codebold
  • 51
  • 3

2 Answers2

2

I don't find any draft beyond the last one (expired since June 2008). I am not aware of any existing implementation. Anyway, the draft is incomplete and inconsistent (e.g. the ContentFormat type is defined twice, with distinct incompatible values; the tls_sign value is undefined) and quite poorly explained (from what I can see, it says nowhere what is actually signed).

Anyway, non-repudiation is a legal concept. It may rely on some technological elements, such as cryptographic signatures and certificates, but these elements cannot ensure non-repudiation alone. To really get non-repudiation, you need to follow what the local legal system says about non-repudiation. When such laws exist, they invariably insist on the idea that whoever is signing must be aware of what he is signing. Thus, signatures for non-repudiation cannot really exist as an application-independent feature -- which was the goal of that draft and its raison d'être as a TLS extension. In that sense, the draft was useless, which explains why it did not result in a complete RFC.

(Uselessness cannot always prevent features from becoming RFC, but it may still siphon out the motivation of who is doing the writing. Writing a publishable RFC is a lot of work, in particular editorial work, which won't happen unless the author is really convinced that it is worth the effort.)

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • If we focus not on legal but on [cryptographic](https://en.wikipedia.org/wiki/Non-repudiation#In_security) meaning of non-repudiation, can you confirm that TLS response is not an equivalent of message digitally signed by the server? – modular Aug 22 '17 at 14:30
  • I see your other answer clarifies this: https://security.stackexchange.com/a/6732/151110 – modular Aug 22 '17 at 14:36
0

I don't know about TLS Sign, but if I had to venture a guess, it was likely dropped because PKI provide a certain level of Non-repudiation through CA's. TLS is an encryption protocol, it's primary purpose is encryption. Non-repudiation is generally considered a separate service in those regards.

Digital Certificates are what we typically use for standard non-repudiation, it provides a common platform for two unknown parties to trust that each other are legitimate connections.

A company for instance, must register its Certificate with a CA, companies than go through some sort of validation to establish the legitimacy to the company saying who they are. Once a certificate is issued a user can verify a presented certificate, with the trusted CA's, and know that the connection they are establishing is a secured connection with a company that has passed their screening.

Since this can get long, I know there are concerns with how good PKI actually is, and security around certificate authorities.

Non-repudiation is nice, but TLS isn't focused on that. We use the PKI with TLS to provide both encryption and Non-repudiation, if you are looking for a higher degree of non-repudiation (such as ensuring a file is send by a certain user or company) TLS would not be the right place in my mind.

-Edit Typos and clarifications

Shane Andrie
  • 3,780
  • 1
  • 13
  • 16