On 9/6/13 7:02 AM, John C Klensin wrote:
...It may still be good protection against more casual attacks, but we do the users the same disservice by telling them that their transmissions are secure under those circumstances that we do by telling them that their data are secure when they see a little lock in their web browsers. Certainly "encrypt first, authenticate later" is reasonable if one doesn't send anything sensitive until authentication has been established, but it seems to me that would require a rather significant redesign of how people do things, not just how protocols work.
Actually, I think the latter is really what I'm suggesting. We've got do the encryption (for both the minimal protection from passive attacks as well as setting things up for doing good security later), but we've also got to design UIs that not only make it easier for users to deal with encrpytion, but change the way people think about it.
(Back when we were working on Eudora, we got user support complaints that "people can read my email without typing my password". What they in fact meant was that if you started the application, it would normally ask for your POP password in order to check mail, but you could always click "Cancel" and read the mail that had been previously downloaded. Users presumed that since they were being prompted for the password when the program launched -- just like what used to happen when they "logged in" to read mail on their Unix/etc. accounts -- the password was protecting the local data, not that it was only being used to authenticate to the server to download mail. You'd ask them why they weren't so worried about people reading their Microsoft Word files and they'd give you dumb looks. Sometimes you do have to redesign "how people do things".)
pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478