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