I've written before about ZUI (Zero user interface) in crypto, and the need for opportunistic encryption based upon it. Today I want to further enforce the concept by pointing to mistakes we've seen in the past.

Many people don't know it, but our good friends at Microsoft put opportunistic encryption into Outlook Express and other mailers many years ago. And their mailers were and still are the most widely used. Just two checkboxes in MSOE allowed you to ask that it sign all your outgoing mail, and further to encrypt all mail you sent to people whose keys you knew. If they signed their outgoing mail, you automatically learned their keys, and from then on your replies to them were encrypted.

However, it wasn't just two checkboxes -- you also had to get an E-mail certificate. Those are available free from THAWTE, but the process is cumbersome and was a further barrier to adoption of this.

But the real barrier? Microsoft's code imagined you had one primary private key and certificate. As such, access to that private key was a highly important security act. Use of that private key must be highly protected, after all you might be signing important documents, even cheques with it.

As a result, every time you sent a mail with the "automatic sign" checkbox on, it put up a prompt telling you a program wanted to use your private key, and asked if you would approve that. Every time you received a mail that was encrypted because somebody else knew your key, it likewise prompted you to confirm access should be given to the private key. That's the right approach on the private key that can spend the money in my bank account (in fact it's not strong enough even for that) but it's a disaster if it happens every time you try to read an E-mail!

We see the same with SSL/TLS certificates for web sites. Web sites can pay good money to the blessed CAs for a site certificate, which verifies that a site is the site you entered the domain name of. While these are overpriced, that's a good purpose. Many people however want a TLS certificate simply to make sure the traffic is encrypted and can't be spied upon or modified. So many sites use a free self-signed certificate. If you use one, however, the browser pops up a window, warning you about the use of this self-signed certificate, and you must approve its use, and say for how long you will tolerate it.

That's OK for my own certification of my E-mail server, since only a few people use it, and we can confirm that once without trouble. However, if every time you visit a new web site you have to confirm use of its self-signed key, you're going to get annoyed. And thus, while the whole web could be encrypted, it's not, in part due to this.

What was needed was what security experts call an understanding of the "threat model" -- what are you scared of, and why, and how much hassle do you want to accept in order to try to be secure?

It would be nice for a TLS certificate to say, "I'm not certifying anything about who this is" and just arrange for encryption. All that would tell you is that the site is the same site you visited before. The Lock icon in the browser would show encryption, but not any authentication. (A good way to show authentication would be to perhaps highlight the authenticated part of the URL in the title bar, which shows you just what was authenticated.)

In E-mail, it is clear what was needed was a different private key, used only to do signing and opportunistic encryption of E-mail, and not used for authorizing cheques. This lesser key could be accessed readily by the mail program, without needing confirmation from the user every time. (You might, if concerned, have it get confirmation or even a pass code on a once a day basis, to stop e-mail worms from sending mail signed as you at surprising times.)

Paranoid users could ask for warnings here too, but most would not need them.

TLS supports client side certificates too. They are almost never used. Clients don't want to get certificates for most uses, but they might like to be able to tell a site they are the same person as visited before -- which is mostly what the login accounts at web sites verify. A few also verify the account is tied to a particular e-mail address, but that's about it.

Perhaps if we move to get the client part working, we can understand our threat model better.