- From: John C Klensin <john-ietf@jck.com>
- Date: Tue, 14 Dec 2010 14:23:45 -0500
- To: Steven Bellovin <smb@cs.columbia.edu>
- cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Common@core3.amsl.com, General discussion of application-layer protocols <apps-discuss@ietf.org>, Yoav Nir <ynir@checkpoint.com>, websec <websec@ietf.org>, - Next Generation <kitten@ietf.org>, http-auth@ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, saag@ietf.org
--On Monday, December 13, 2010 13:57 -0500 Steven Bellovin <smb@cs.columbia.edu> wrote: >... >> Just like the phrase "I am not a lawyer" is always followed >> by amateur legal advice (I know that for sure, I've done it >> myself), the same goes for "I am not a UI expert". >> >> Two comments: >> >> - There are in fact a few security-usability experts. I don't >> know if any of them participate in the IETF. This is an >> emerging research field, see e.g. >> http://oreilly.com/catalog/9780596008277. >> >> - (I am not a UI expert, but...) Devising UI cues is >> extremely difficult. People will gladly enter their password >> when the web site displays a JPEG-rendered padlock icon. In >> fact *legitimate* sites have been known to display such >> icons, strange as it may sound. > > Security and usability *is* one of my research areas. I agree > with Yoav: there are many problems with use of client-side > certificates. In general, I like them -- the only way to log > in to the computers I control is with public-key authenticated > SSH -- but there are very good reasons why they are seldom > used. Private key storage and transport is the major one, but > key issuance and recovery from lost or stolen keys are serious > issues as well. The security community has made that worse by > layering heavyweight policies and procedures on top of the > certificate issuance process, even when the value of the > resource being protected isn't high enough to justify it. > > (I've been worrying about usability issues for a long time. > There was one I-D that I dealt with as AD that I abstained on > -- I wouldn't vote "no-ob" because I did object, but I had no > better suggestion than "go back and start over". While > dealing with that document, I emailed one of the top usability > people and asked > > Do you know of papers on the difficulty of administering > complex access control lists? I'm trying to convince people > that a seriously-complex scheme will lead to massive > security failures, because no one will be able to get the > ACLs right. > > So yes, there are people in the IETF who worry about UI > issues.) Steve, I worry too. And, while I effectively dropped out of the field --in terms of making any useful contributions-- about 25 years ago, I do try to track the literature (without great success). Observations: (1) The folks who taught me about what was then called "human factors in computing" in the 70s suggested that one key issue was to design from error/failure states backwards to both detailed system design and UI. If one could not do an analysis of failure states, then one wasn't ready to design the interfaces of the system. If the right information is not available in the right place to produce a coherent message and make it actionable, patching things on just don't work. From that perspective, it is as hard or harder to graft a good UI onto a system that wasn't designed with UIs in mind as it is to graft good security onto a system that wasn't designed for that. A large number of modern systems --and IETF protocols-- fail on both dimensions. (2) Even without any research, it should be obvious to us all that presenting a user with a dialog box with a string of text that might be informative to an expert but is pure gibberish to the user, followed by some choice, is not going to produce good results. The question of whether the choice in that situation should be a pair of boxes labeled "yes" or "no" (or equivalent) or a single box labeled "ok" (or equivalent) is, IMO, of purely academic concern. Unless the user can make an informed decision, decision/dialog boxes or other types of questions aren't about UIs but about attempted sops for the conscience of the implementer. Almost everything I've seen that attempts to deal with certificate validation failures falls into that general category. Things would be considerable better if we never had a false negative (bad certs could just be rejected, action dependent on them stopped, and the user informed, not asked), but that seems unlikely at least as long as we have relatively simple cases like administrative failures to install new certs before old ones expire. (3) I think the above suggests that your "seriously complex scheme" criterion is much too high a bar. Even a moderately complex scheme that depends on lots of factors or subtle interactions will fail. If the ACLs don't get people, then user inability to deal with explanations of the failures will. (4) The problem with your comments, and even more so the problem with mine above, is that they are not usefully actionable in the IETF. We could round up a collection of UI experts to look at some of these things and have them shake their heads and say "royal mess you have gotten yourselves into". That, like your comments and I hope mine, would be true... and equally useless vis-a-vis digging ourselves out. I hope this isn't as hopeless as it feels to me sometimes, but... do you have suggestions? john
Received on Tuesday, 14 December 2010 19:24:25 UTC