--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