Re: Draft charters available; please comment.

On 2006-07-05 11:15:23 -0700, spam filter wrote:

>>    * a W3C Recommendation that describes an annotation
>>    mechanism that supports at least HTTP Digest
>>    Authentication, and possibly other authentication
>>    mechanisms as the working group sees fit

> I'm not as familar with these requirements.  It looks like
> we're specifying an annotation of authentication meta-data.
> Would we reference some other standard to provide the
> authentication mechanisms?

The basic idea is that, currently, HTML forms are used to ask
for credentials such as passwords; the credentials are then
submitted by way of HTTP POST.  If there are protocol-level
authentication mechanisms (such as Digest) available, then
there is no way to dispatch the credentials to these mechanisms.

The idea is to tell the user agent that such a mechanism is
available, and that he can please dispatch the credentials to
that mechanism, as opposed to usual form submission.

> I'm not sure about calling out HTTP Digest Authentication,
> since its broken.  The offline dictionary attack on the
> digest credential requires under 1 second of CPU time to
> break most passwords.  Rather, we could define an annotation
> which is implementation neutral and agree on some
> specification for picking the implementation.

To some extent, that's the purpose of the "and possibly other
mechanisms as the working group sees fit" language. 

> http://www.w3.org/2005/Security/wsc-charter
> 
> >Current Web user agents communicate only a small portion of available
> security context information to users in a way that is easily
> perceived and understood. Other secontext context information that
> might be available to user agents and possibly helpful to users is
> either not presented, or presented in a way that is not understood by
> users, and hence useless or confusing. This information ranges from
> logotypes and company names and addresses that might be present in PKI
> certificates, to the user agent's memory of past activities.
> 
> >Where the mechanisms that are used to communicate context information
> can be overridden by Web content, they also open the scene for
> attackers serving fake security indicators.
> 
> Could we mention personalization and/or unspoofability in this
> charter?  Or is it the intent that be covered by some other working
> group?  For example, how is this edit?
> 
> >Current Web user agents communicate only a small portion of available
> security context information to users in a way that is easily
> perceived and understood. Other security context information that
> might be available to user agents and possibly helpful to users is
> either not presented, or presented in a way that is not understood or
> spoofable,  and hence useless or untrustworthy. This information
> ranges from personalization, to logotypes and PKI certificate
> meta-data, to the user agent's memory of past activities.
> 
> 
> "can be overridden by Web content" is a tricky phrase.  I would say
> "can be effectively spoofed by Web content" as a more precise, 1
> sentence description of the threat model.   

These are a bit different: "Overridden" refers to scripting's
ability to remove some elements from the display.  "Spoof"
includes things like the picture in picture attack, which is
much more tricky to counter.

> I would expect a solution to address the picture in picture
> attack and incorporate sufficient training of users in
> recognizing spoofing attacks.
> 
> For example, a solution which allows for personalization may
> not be sufficient if it doesn't train the user to utilize
> the personalization and recognize spoof attacks on that
> personalization.

I'll play with some edits to the scope text to take up these
points.

-- 
Thomas Roessler, W3C   <tlr@w3.org>

Received on Wednesday, 12 July 2006 22:30:31 UTC