Financial Cryptography

Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(

Back in the good old days when security people would sprout nonsense and nobody blinked, we talked about non-repudiation as a feature of public keys. Finally, we blabbered to anyone who would listen, we can prove that the bad guy is bad, through adroit application of PAIN and other suitable acronyms.

I was put straight on this issue by a post on the cryptography list several years back (many thanks to Carl Ellison). Basically, non-repudiation is a contradiction, as there is no way to stop a person repudiating something. She simply says

"I did not!"

And now it is over to the two sides to prove it or otherwise. Which is to say that repudiation is a basic human act, and it is a foundational stone of our modern juridical system; one side makes a claim, the other side disputes it. In court, before an impartial judge.

The term "non-repudiation" is nonsense. Even worse, the technology didn't even come close to that sense, because of the whole security mess known as the PC. Ellison & Schneier said simply that "it is your machine signing for another machine," which I long-windedly refer to as a failure to anthromorphise the PC: we have no good theory to relate a human to a key.

And, in more formal legal terms, it's a straightforward case of agent-principal failure, in that there is no clear agent-principal relationship between a natural person and a PC; given the predominant security record of Microsoft and competitors, there is no real hope for ever pushing the fantasy in court that the PC is acting for the user.

So .... as a security field, a lot of us have been beating the drum that non-repudiation does not exist in practicality, it's a hype feature only. And digital signatures aren't human signatures. And... (read my collected PKI grumble list for more).

One small contribution I might have been responsible for was the perspective that we should be talking about evidence, not signatures. Protocols reveal evidence. As anyone who's been through the mill of the legal process will tell you, anything can be evidence, and it is up to the court to decide what is good evidence and what is bad.

Hence, our role as architects is to think in terms of the quality of evidence. How can we improve the conclusions drawn from the events and logs? Well, one way is to use PK digital signatures, with the caveats of compromised keys and so forth. Another way is to use hash chains and entanglement, with the caveats of compromised PCs and so forth. Then there are timestamps, and written statements, and ... the list goes on.

By way of personal example, the Ricardian Contract gets it right, because it thrusts a human readable document out there in front of ... humans! It isn't the digsig that helps, it is the fact that the human who signed cannot be unaware of the document, normal circumstances pertaining. So as time goes on, the chances of the contract issuer "repudiating" his own contract diminish dramatically. Cunning tricks like that are the meat and drink of financial cryptography -- getting into the core of the real finance application and understanding how they tick; and then designing systems to help them tick better.

Which long preamble brings us to an Internet Draft entitled "Transport Layer Security (TLS) Evidence Extensions." This document purports to add an "evidence" extension to the venerable but ever popular TLS protocol (a.k.a. SSL, secure browsing and all that). From the introduction:

Evidence created using this extension may also be used to audit various aspects of the TLS handshake, including the cipher suite negotiation and the use of other TLS extensions. In many cases, the evidence does not need to be validated by third parties; however, in other cases, the evidence might be validated by third parties. To accommodate all of these situations, the evidence is generated using a digital signature.

Now ordinarily I would applaud this "single-minded approach" as a very useful employment of my hypothesis of "there is only one mode, and it is secure." But, from the Overview:

Generating evidence is not compatible with Diffie-Hellman Ephemeral (DHE) key exchanges. DHE does not permit the same keying material to be generated for validation of the evidence after the TLS session is over. Persistent evidence requires the use of a digital signature so that it can be validated well after the TLS session is over.

I beg to differ! As I mooted above, evidence is what you present to the court; A DHE session will do nicely thank you very much as it can log information that can be utilised for evidentiary purposes: time logs, successful password usages, etc.

So why the need to eliminate classes of evidence? More from the body:

Persisten[t] evidence of the TLS session content is produced by the TLS Evidence Protocol.
[Ed: my slight correction of word persistence used in the ID.]

What we have is a new chance at the old non-repudiation trick. That trick goes like this: First, we redefine the term "Evidence" to be what we want. Then we deliver what we want, calling it all the time Evidence. Then we force people to adopt Evidence because evidence is needed.

Nobody notices there are two disparate definitions until it is too late and they have adopted it, but that's ok because the mission is adoption, not evidence.

This would be OK if Evidence delivered anything useful. But, as we described above:

When digital certificates are to be employed in evidence creations, the client must obtain the public key certificate (PKC) for the server, and the server must obtain the PKC for the client. This is most easily accomplished by using the PKCs provided in the Handshake Protocol Certificate messages. Further, both parties SHOULD have an opportunity to validate the PKC that will be used by the other party before evidence creation. Again, this is naturally accomplished using the Handshake Protocol, where the TLS session can be rejected if the PKC cannot be validated.

Spot the problem? The client they are talking about is software, but the party they are talking about is the poor dumb victim behind the PC. Call it agency-principal failure or anthromorphism failure, it's still failure, and the security threats inherent within are unrecognised in the document despite a long history (and a very clear heading entitled 6. Security Considerations).

So what is it that they want? It looks to me -- my personal opinion -- like the same old same old: "we" need a way to push various groups into mandating PKI key infrastructure, a la the many and various agency dreams from a decade ago. Sarbanes-Oxley and others create a need for compliance, and evidence feeds into compliance.

The two come together: create a web of technical blah blah that leads to a claim that TLS delivers the Evidence, the whole Evidence, and nothing but the Evidence. Then convince everyone to accept this future RFC via the unimpeachable IETF standards process, those stalwart protectors of the Internet. Then take the RFC and push it before the regulators eyes -- if they have our Evidence, then they have your Compliance with Sarbanes-Oxley.

The hope is that another bunch of suckers will be duped into pushing PKI into inappropriate places. This simply won't work. Indeed, the way it treats evidence is so callous that it probably (my LLB U.Gresham coming into play here) makes matters worse. The evidence it produces will likely not be useful nor reliable in court, and it may even be dangerous because of the false sense of security generated. E.g., there will be enough expert witnesses around to testify that it is useless, and the added complexity will cause all sorts of problems.

And it will certainly slow down the usage of TLS or similar security processes, which is the last thing anyone wants. A security protocol used is far more secure than one not used because the barriers to adoption are too high.

Posted by iang at January 5, 2007 10:16 AM | TrackBack