Re: [IanG] Re: More US bank silliness ( LC-2094)

 Dear Sam Hartman ,

The Web Security Context Working Group has reviewed the comments you sent
[1] on the Last Call Working Draft [2] of the Web Security Context: User
Interface Guidelines published on 24 Jul 2008. Thank you for having taken
the time to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-usable-authentication@w3.org if you agree with it or not before 28
January 2009. In case of disagreement, you are requested to provide a
specific solution for or a path to a consensus with the Working Group. If
such a consensus cannot be achieved, you will be given the opportunity to
raise a formal objection which will then be reviewed by the Director
during the transition of this document to the next stage in the W3C
Recommendation Track.

Thanks,

For the Web Security Context Working Group,
Thomas Roessler
W3C Staff Contact

 1. http://www.w3.org/mid/tsly721twpl.fsf@mit.edu
 2. http://www.w3.org/TR/2008/WD-wsc-ui-20080724/


=====

Your comment on :
> Forwarded at the author's request.
> 
> The author has one comment that I kind of agree with fairly strongly.
> The current document does not handle the issue of key life cycle
> management for self-signed certificates well.  I tried to see if the
> security community (in particular the security directorate) within the
> IETF was interested in giving you guys some guidance here, but found
> no takers to try and put together a consensus.
> 
> Things I'd consider if I were giving guidance in that space would
> include:
> 
> * expiring the binding between a site and certificate when that
> certificate expried
> * allowing one certificate signed by a particular root certificate that
> does not chain to a trust anchor to replace  another chaining back to
> the same root
> 
> 
> ---
> 
> Hi Sam,
> 
> Sam Hartman wrote:
> 
> > Peter, list, the W3C W Web Security Context working group is in the
> > final week of a public last call on their user interface guidelines.
> > These guidelines take a lookboth at the balance between EV-certs and
> > at user interface for security indicators.
> > 
> > Comments need to be received by September 15. The draft is at
> > http://www.w3.org/TR/2008/WD-wsc-ui-20080724/ and my take is at
> > http://www.painless-security.com/blog/2008/08/w3sc-lc/ .
> 
> 
> Hmm.  I read that.  I regret to say I find it unlikely anyone from
> the user interface community will find it useful.  Here's my
> comments.  Feel free to forward them to someone, I'm not part of the
> W3C, and I have little clue about the context.  I'm sure that shows...
> 
> First the good one, then the rest.
> 
> 
> 
> Promoting Petnames would be a substantial improvement in UI
> practices.  This document more or less supports them, but, unlike
> its promise, does not describe why they are so useful, and
> importantly when to use them (suggest to user) rather than any
> alternate.  We are very far away from useful guidance.
> 
> In contrast to petnames, there is little commentary on key
> continuity management.  These are very close to petnames, is the
> point that we may as well just implement petnames?
> 
> 
> 
> Overall.  The document is very hard to read.  It is written in
> extremely difficult language, uses many definition of specious
> utility, and this use of internal code hides its essential
> recommendations.
> 
> Until I realised that this was written by PKI developers for other
> PKI developers, I was appalled.  It was not written by user
> interface people and not for user interface people.  It has
> mountains of PKI assumptions, truisms and commercial aspirations in
> it, and by the time we get to the brief user interface guidance in
> sections 6,7 the way is lost.
> 
> At least I figured out that much.  So, probably, it could best be
> fixed by changing the title to "Guidelines for PKI Developers" and
> starting again, if there are user interface people who want some
> guidelines.
> 
> 
> 
> 
> 3.  Conformance seems inappropriate.  How can one be conformant with
> Guidelines?  What happens when a UI developer finds a new way of
> doing things?  Is the book on user interface design written?
> 
> It would seem far better to say "We don't know how to do this.  But
> here are some top tips..."
> 
> 3.3  It mixes terms and standards inappropriately.  How can
> "advanced conformance" be construed to be all "SHOULDS" in a
> Guideline for user interfaces?  It makes no sense.
> 
> 3.4.2 This obsession with "strong" TLS is misplaced.  No phisher
> ever worried about it, why should we?
> 
> 3.4.3 "broadly accepted practices <-> augmented assurance <-> MUST
> do this..." pushes the agent to make decisions that are well beyond
> its capability.
> 
> The notion that a browser or equivalent would create a separate
> class of "augmented" versus "validated" certificates has to be
> treated with great suspicion.  At a minimum, the browser's legal
> counsel needs to be involved in the entry into the active security
> process of the user.  It is not a thing for browser developers to
> treat as "just another setting in the profile".
> 
> 
> 
> 
> 
> 4.2.1  Primary & Secondary seems over-strained.  What is wrong with
> agent-directed and user-initiated actions?  Its use in the text
> indicates a specious distinction that then took on a life of its
> own.  It is entirely a mystery as to why the robot is primary and
> the user is secondary, but there has to be an inner message here.
> 
> 
> 
> 
> 5.1.2 this is tortured.  As a matter of legal interpretation, the
> "MUST use O field" makes for a claim that "companies can be
> identified better than individuals" which is a nonsense.
> 
> "augmented assurance" seems to be a shoe-in for EV.  That's no
> problem, but not everyone agrees that EV should be given special
> treatment.  especially, the conclusion that "giving some company
> some subsidy" is hard to avoid if it involves special treatment.
> 6.1.2 concurs with "special treatment".
> 
> 5.1.3 this is getting more tortuous.  The world is divided into
> "Ordinary Validated certificates" and "augmented certificates" ...
> and the former are "domain validated" only, attests to a binding
> between a domain name registration and a key pair; additional
> certificate attributes are often not validated!!!!
> 
> This document appears to have swallowed the EV kool-aid.  It appears
> to have sided on the EV group in order to support the barriers to
> entry in the CA business.
> 
> 5.1.5  Incorrect: "In both situations, use of TLS provides
> confidentiality protection services against passive attackers. No
> binding of a third-party asserted identity to the cryptographic key
> is achieved."
> 
> SSCs can provide protection against active attackers where key
> continuity management is in place.  The asserted identity is bound
> by the 1st party, not a 3rd party as with CA-signed certificates.
> 
> 
> 5.1.6 "When the user assigns a petname, the petname presentation
> implementation MUST warn the user if the chosen petname is similar
> to one currently in use."
> 
> Can't use MUST to enforce a similarity...  SHOULD be SHOULD.  (there
> is a difference between a bug and a user interface guideline!)
> 
> ...
> 
> Proper Reference to petnames is needed.  I would suggest:
> http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
> 
> 5.2.  Worrying about export ciphers and TLS "known flaws" is a joke.
>  Their presence or otherwise has never stopped phishers exporting
> users' money across borders.  They are nowhere near the user
> viewpoint nor understanding.  We should be focussed on validated
> security threats, not the bogeymen from the last century.
> 
> 
> 
> 
> 6.1.1
> 
> "This [Definition: identity signal ] SHOULD be part of primary user
> interface during usage modes which entail the presence of signalling
> to the user beyond only presenting page content. Otherwise, it MUST
> at least be available through secondary user interface."
> 
> This really tears the rug from underneath all the security
> foregoing.  As this provides an option to bury it in some "special
> user-directed interface" it essentially says "do whatever you want."
>  The rest is equally problematic.  Here is what I reduced it to:
> 
> =============
> The identity signal SHOULD appear in a consistent visual position.
> Web Content MUST not obscure security chrome
> 
> User interactions to access this identity signal MUST be consistent
> across all Web interactions facilitated by the user agent.
> 
> If the Web user agent has no trustworthy information about the
> identity of the Web site that a user interacts with, this MUST be
> clearly indicated.
> 
> If the unauthenticated or untrusted sources are displayed, and a
> positive identity is available, this must also be displayed and
> related clearly.
> ==============
> 
> Now, obviously some subtlety might be missed in the above, but
> that's a subtlety that will clearly be missed by any user interface
> developer, as well.
> 
> 
> 6.1.2
> 
> Weird.  "AA"s do not include the certificate issuer's name, so their
> pedigree before the user is unknown.  How is the user to evaluate
> whether the claim means anything?
> 
> Meanwhile, the validated certificate result MUST include the
> Issuer's Organization field.  So this is stronger than the AA, for
> the user, because the entire claim is laid out.  This is how it
> should be, but I wonder if the author made a mistake?
> 
> Whether you lay logo types out or not needs to be better stated.  At
> the moment, it is couched as a "reward" for using an AA.  Entering
> into commercial battles for market space is not a wise thing for a
> standard to aspire to.
> 
> Rather, there is should be something like:
> 
> ===========
> "A clear signal such as a consistent colour should be used for each
> level of validation (e.g., augmented, validated, petnamed, KCM, SSC,
> plaintext HTML, warning, etc.)."
> ===========
> 
> 
> "Note that this behavior does not apply when self-signed
> certificates or certificate chains that chain up to an untrusted
> root certificate are used."
> 
> So, what is the user interface guideline for this?  Or is this not a
> user interface guideline, but a different document?  It should look
> like this:
> ==============
> "During interactions with an unknown SSC, the agent shows:
>    * the basic information
>    * a signal of caution
>    * a choice to accept and petname, if implemented
> ==============
> 
> 
> 6.2  Seems reasonable!!!!
> 
> 6.3  So, the TLS indicator is able to light up if only signed, or
> only encrypted, or some combination of above?
> 
> TLS does several things.  These things are only related in the minds
> of the protocol engineer, not the minds of the user.
> 
> There should be a separate indicator for IDENTITY and another
> ENCRYPTION.
> 
> 6.4.1
> 
> "Error signalling that occurs as part of primary chrome SHOULD be
> phrased in terms of threat to user's interests, not technical
> occurrence."
> 
> No.  the developer has no clue what the interests of the user are,
> and doesn't even know what site she is on.  If the developer tries
> to guess what her interests and threats are, he ends up confusing or
> offending the user, and probably reducing the overall security.
> 
> This is why the original model was about "simple."
> 
> Instead, focus on claims that the user can understand.  E.g.,
> 
>    "The CA XYZ states that this site is ACME Inc."
> 
> OR:
> 
>    "There is an error;  although the site identifies itself as ACME,
> the domain is from www.someoneelse.com.  This could be an attack."
> 
> 
> 
> 
> 7.2 specious reference:
> https://financialcryptography.com/mt/archives/000179.html
> 
> 
> 
> 8.3   Hooray!


Working Group Resolution (LC-2094):
Thanks. 

We decided not to take on additional recommendations on the key lifecycle
of self signed certs. 

We've added a reference to KCM. 

We have removed the compliance language around petnames, and left
discussion of it in the security considerations section. 
We've added this reference for petnames:
http://www.hpl.hp.com/techreports/2005/HPL-2005-148.html

We've made the association between augmented assurance certificates and
the implementation of them with extended validation certificates a bit
clearer by ensuring that AA references EV when it first appears in the
specification. 

We removed the specious reference. 

The identity signal sections call out the identity part of TLS as a
separate and clear concept. We leave it to the UI designer to determine
the exact relationship between the two. 

Much of the discussion of logotypes has been removed due to lack of
implementation and testing (a core requirement in the specification
process for moving any of the recommendations ahead). 

We are drafting text that attempts to clarify the relationship between
guidelines and specifications and the relationship to PKI: 

@@update once tweaked
This document specifies user interactions with a goal toward making
security usable, based on known best practice in this area. This document
intends to provide user interface guidelines but assumes that the audience
has a certain level of understanding of core PKI (Public Key
Infrastructure) technologies. Since this document is part of the W3C
specification process, it is written in the form of a standard, with the
requirements and options for conforming to it as a standard clearly laid
out. User interface guidelines that are not intended for use as standards
do not have such a structure. Readers more familiar with that latter form
of user interface guideline are encouraged to read this specification as a
way to avoid known mistakes in usable security. 

----

Received on Wednesday, 21 January 2009 20:26:09 UTC