Web Security Context WG Teleconference
11 Apr 2007

approval of minutes from last meeting

<tlr> http://www.w3.org/2007/04/04-wsc-minutes

minutes approved unimanimously

closure of action items

I would reather use my own mute

<tlr> all agree, ACTION-154 ACTION-157 ACTION-160 ACTION-166

tahnks

<Tyler> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals

Safe Browsing Mode

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0217.html

<tlr> PROPOSED: defer; Dan Schutzer to present at a later time

topic deferred

<ses> <---got only 90 minutes of sleep last night so may not be here in much more than electronic form only.

Virtual hosting and TLS related material

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0051.html

PHB: ssl as designed assumes one to one between IP addr and certificate

host name checking is not checked carefully

but when it it is it causes problems

starting to cause problems

with EV certificates

<tlr> hal, for continuation lines, please use this syntax:

<tlr> ... this goes on ...

<tlr> ... and on ...

ok

<tlr> Also, please attribute what's said.

<tlr> It'll all make you rlife much easier when you get to clean-up. ;-)

scribe: fix is being deployed
... only on client side
... need server side support

<Zakim> tlr, you wanted to ask what the recommendation in scope for us would be

phb: clients support tls hostname extension

<tlr> PHB: client providers ought to support TLS host name extension, server providers support use of that feature

tlr: what about error condition - page reload?
... from airport hotspot

(sorry can follow usecase can you type it)

cant

phb: related piece is can solve by being more lax in checking redirects

<tlr> tlr: related, hotspots doing benevolent SSL MITM. Do we need a "override, but just send GET / HTTP/1.0" instead of doing the post here?

phb: people don't type the "www" part of domain name
... so redirect gives error
... before you could get by
... now doing checking at TLS level, before redirect

chuck: related issue mapping IP names to certs
... multiple servers or caching servers
... will break a lot of existing solutions
... will IETF fix solve all these

phb: will not solve all the issues
... cause is checking things more carefully
... will see more errros if not careful
... another fix which could be used is wildcard domains
... currently prohibited by EV rules
... revocation can be an issue
... IETF fix allows multiple sites on physical servers

chuck: problem EV certs my produce too many errors
... users will work around, undermine effectiveness

<serge> Zakim mute me

<Zakim> tlr, you wanted to ask about technical constraints that are in EV guidelines

chuck: don't have answers

tlr: + 1 to chuck
... question to phb are EV x.509 profile published

phb: is a profile of PKIX profile

tlr: can share pointer?

<tlr> ACTION: hallam-baker to share pointer to CABforum profiling of PKIX [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action01]

<trackbot> Created ACTION-189 - Share pointer to CABforum profiling of PKIX [on Phillip Hallam-Baker - due 2007-04-18].

phb: propose we point to work of others, not design

<tlr> ACTION: hallam-baker to attempt summary of discussion and proto recs re EV and virtual hosting in wiki [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action02]

<trackbot> Created ACTION-190 - Attempt summary of discussion and proto recs re EV and virtual hosting in wiki [on Phillip Hallam-Baker - due 2007-04-18].

<Chuck> The CA Browser forum appears to have links to download the relevant documents (cleverly hidden) at the very top of their home page at: <http://cabforum.org/index.html>

PII editor bar

<tlr> http://www.w3.org/2006/WSC/wiki/PersonallyIdentifiableInformationEditorBar

tyler: want to get indication to user when about to enter sensitive data
... user will type into editor widget
... login scenario
... remembers text used for login

<tlr> I'd suggest calling the thing "Sensitive Information Bar" or some such.

tyler: lets you select one to use
... moves cursor to editor widget
... provides indication that have provided password previously
... interupts normal flow if at different site
... next to it is petname tool
... can show no relationship to site
... or just msg talking to stranger

BobP: question select password from pull down?

tyler: no, will have list of sites in pull down

bob: would see password?

tyler: have some choices, could have it displayed or have stars

bob: display could allow others to see it

tlr: I would avoid PII term here
... call it your information entry
... interaction mode when entering data?

tyler: other aspects
... try to implement failure case
... use of petname tool to identify site

<tlr> I had suggested that a high-level description of this would be to (a) put users into different interaction mode when they think they are making another trust decision, and (b) leverage stored information to signal that user is actually repeating a prior security decision.

<Zakim> Thomas, you wanted to note that the reliability issue is better dealt with in HTML WG and to also come back to PII discussion

tlr: reason not to use PII brings up rathole, want to control when we treat these issues
... data can be not PII in some cases
... not accurate decsription of what we are talking about
... reminded me of HTML form idea of filling fields
... can deal with in w3 forms group

tyler: not good idea to make html specific

thanks

tyler: need hal: cant do form fill combined with stars display

sduffy: how determine previously trusted site

tyler: petname tool does it - explicit user choice

tlr: need to seperate abstract concept from detailed interface

<tlr> ACTION: tyler to update TrustMe proposal in wiki [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action03]

<trackbot> Created ACTION-191 - Update TrustMe proposal in wiki [on Tyler Close - due 2007-04-18].

UrlRecommendation

<tlr> http://www.w3.org/2006/WSC/wiki/UrlRecommendation

mez: in favor of short recommendations to discuss
... 1st is URLs
... talked about how they are used, mostly for security
... heard some browsers were doing more with contents of URL
... want to discuss this, what are browsers doing?
... have heard users cannot understand URLs
... few restrictions, no mechanisms to insure understandable by users
... 2 levels of risk
... low and no risk situations, can be identified?
... in this case can be presented for usability, not security
... in medium to hi risk, meaningful and robust presentations required
... what about display?

<tlr> "Your flight has been cancelled."

mez: only way to get at understandable properties in URL is from history of interation

tyler: assumes part of URI is of interest to user, what part?

mez: ties to something about authority faliliarity trustworthiness
... may note be substring

tyler: better not to display URL
... want to pin down value if any of URL display

tlr: you're mixing display and entry of URLs. I sense that it might be useful to have a generic "drop URL bar" discussion. Please draft a proposal.

tyler: seems to be some overlap

<tlr> ACTION: tyler to draft "let's drop the URL bar" proposal [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action04]

<trackbot> Created ACTION-192 - Draft \"let\'s drop the URL bar\" proposal [on Tyler Close - due 2007-04-18].

chuck: different take, nobody understands URLs, things get entered by click
... used to just be reference

. may be providing lots of info, session, forms info

scribe: some useless some dangerous
... need to consider what info is actually being provided
... sometimes intentionly invisible

scribe: potentially complex
... what is boundary?

mez: not just browsers location bar
... glad you brought in relationship between click link and URL value
... will update wiki

<tlr> http://www.w3.org/2001/tag/doc/state.html

<tlr> I think I provided a high-risk example on IRC. "Your flight has been cancelled."

mike: are display only cases which are hi risk, will provide examples on request
... main point most users ignore location bar
... but need to consider those who do
... browsers don't indicate domain
... consider https to be more reliable indicator than padlock

<tlr> ACTION: mcCormick to provide high-risk display-only use cases [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action05]

<trackbot> Created ACTION-193 - Provide high-risk display-only use cases [on Michael McCormick - due 2007-04-18].

hal: dont understand about https, only requires port 443

mike: should get rid of favacon, makes it easy for phishers

<tlr> ACTION: zurko to refine UrlRecommendation - due 20 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action06]

<trackbot> Created ACTION-194 - refine UrlRecommendation [on Mary Ellen Zurko - due 2007-04-20].

SharedPublicKnowledge

<tlr> http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge

mez: techniques for weak identification
... shared between sites, like mothers maiden name is anti pattern
... looking for input

tlr: aim at generic case
... finding that cute icon distracts users from real security info
... anti pattern

chuck: have scars

<tlr> I'm taking that from the Emperor paper

<ses> We could call out "presenting security steps that are necessary as sufficient" as something we'd want to advise against.

chuck: need to be careful about how to characterize SPK
... used by orgs to additional confidence
... mother's maiden name is always bad
... but others may be usuable

chuck: real issue is frequency of use
... key is whipping boy
... some people get irate over SPK term

<ses> In response to the statement that SiteKey is used to authenticate clients, I would disagree. SiteKey is to reauthenticate people. (Once they believe the user of the browser is authentic, they THEN make a transitive assumption that the client belongs to the user)

chuck: some effectively use data shared between user and site
... potential for social engineering - giving the illusion of confirming
... very complex, not always anti pattern, need to say what should be done

mez: agree but should work in parrallel

<tlr> ACTION: zurko to capture discussion on SharedPublicKnowledge in wiki and refine proposal - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action07]

<trackbot> Created ACTION-195 - capture discussion on SharedPublicKnowledge in wiki and refine proposal [on Mary Ellen Zurko - due 2007-04-25].

Contextual Password Warnings

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0138.html

tlr: based on article about warnings given in specific case more effective
... and article about how mashups get auth info
... user enters credentials for A at B
... browser could detect this case

<ses> There's a paper by Microsoft at the next WWW that create a toolbar that looked for password reuse.

tlr: looking for input

<Mez_> hal: prohibits extremely common habit

<ses> "A large-scale study of web password habits" by Florencio and Herley

<Mez_> ... how do you manage 50 passwords?

<ses> It supports what Hal is saying right now.

<ses> (One problem with the proposal is that you don't know its the same password until it has been typed. A malicious site can send characters back one at a time as they are typed.)

tlr: would learn past trust decisions, could suppress question the 2nd time
... space to optimise it

<ses> http://research.microsoft.com/~cormac/Papers/www2007.pdf

<Zakim> Thomas, you wanted to note that we can talk about deployment techniques

chuck: many problems at server side

tlr: agree, charter allows deployment practice
... need concrete proposals

chuck: need mutual security
... one sided approch is always vulnerable

tlr: would like to hear specifics

chuck: group is oriented towards client exclusively

<tlr> ACTION: chuck to turn ramblings about deployment and server side into coherent written material - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action08]

<trackbot> Created ACTION-196 - turn ramblings about deployment and server side into coherent written material [on Chuck Wade - due 2007-04-25].

bill: added section in ?? covering servers

<Zakim> MEZ, you wanted to comment that we should try to make it smarter about trust domains

<tlr> bill-d: offer to help Chuck with ACTION-196; section about web server and connection to user agent

bill: comments to note discuss servers

mez: can consider trust domains

<tlr> ACTION: thomas to incorporate discussion about Contextual Password Warnings into Wiki - due 25 April 2007 [recorded in http://www.w3.org/2007/04/11-wsc-minutes.html#action09]

<trackbot> Created ACTION-197 - incorporate discussion about Contextual Password Warnings into Wiki [on Thomas Roessler - due 2007-04-25].