January 05, 2007

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

> Back in the good old days when security people would sprout nonsense
> and nobody blinked,

Is this an intentional mixing of metaphors, using "sprout" instead of "spout"? It's quite an image! I've never seen it before (or at least never noticed it), but I see you're not the first--google reports 1090 hits for "sprout nonsense" (compared to 19600 for "spout nonsense", so that's more than 5%).

Posted by: Ray at January 5, 2007 05:16 AM

LOL.... well, that would fall in the "unintentional" basket. Now that I think of it, spout would be correct, but as the usage is one of metaphors, maybe I can poetically claim licence that there is a peculiar Brussels sense of talking nonsense ???

At a meta-post level, the precise meaning of words is what it is all about, so corrections gladly accepted.

Posted by: Iang at January 5, 2007 05:23 AM

old post where i pulled some sc27 definitions and added them
into my merged security taxonomy and glossary
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation

non-repudiation exchange
non-repudiation information
non-repudiation of creation
non-repudiation of delivery
non-repudiation of knowledge
non-repudiation of origin
non-repudiation of receipt
non-repudiation of sending
non-repudiation of submission
non-repudiation of transport

non-repudiation shares same issues surrounding "human signature" ... where a "human" signature is indication that somebody is demonstrating *intent* and has read, understood, approves, aggrees, and/or authorizes something ... requiring some sort of indication that holds for each specific operation. "digital signature" carries NONE of those characteristics (other than the terms happen to share the
word "signature"). lots of past posts discussing "human signature" (and having been brought in to help word-smith the california and federal electronic signature legislation)

"non-repudiation" requires something similar ... and as such, many of the definitions have morphed into involving a service that provides some indication as to some specific occurance ... rather than trying to demonstrate non-repudiation of *intent*, demonstrate non-repudiation of some specific event or activity having occured.

a couple of (lengthy) past threads discussing "meaning" of non-repudiation:
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation

Posted by: Lynn Wheeler at January 5, 2007 10:42 AM

I don't agree that non-repudiation is a misnomer or chimera. I do agree that the weakest link is often an insecure signing device (e.g., a PC).

Its true that in its common usage signatures are evidence. If courts are deciding things then repudiations may indeed take place, sometimes even if they were with malice or fraudulent. Individuals or corporations may be forced to accede to unwinding prior commitments or transactions, sometimes with greatly damaging results. Not much you can do if courts are involved.

An obvious if partial solution is, for businesses that can, to effectively operate outside identifiable national jurisdictions. Contracts can be adjudicated by private justice systems (e.g., the Common Economic Protocols) that may be unwilling to preempt existing contractual arrangements (especially, digital/electronic contracts, a 'la ) to satisfy statist or social goals. In that case caviat emptor to signers.

Posted by: Nostradumbass at January 9, 2007 03:24 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.