- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 21 Nov 2007 17:12:28 +0100
- To: public-wsc-wg@w3.org
Minutes from our meeting on 2007-11-06 were approved and are
available online here:
http://www.w3.org/2007/11/06-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Face-To-Face
6 Nov 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Hal Lockhart, Rachna Dhamija, Luis Barriga, Maritza Johnson,
Bruno von Niman, Ian Fette, Tyler Close, Mary Ellen Zurko, Bill
Doyle, Yngve Pettersen, Phillip Hallam-Baker, Thomas Roessler
TAG members for [4]joint session
Tim Berners-Lee, Noah Mendelson, David Orchard, Stuart Williams,
Henry Thompson, Rhys Lewis
Observers
Amit Parashar, Bede McCall, Dave Raggett
Chair
Mez
Scribe
bill-d, yngve, PHB
Contents
* [5]Topics
1. [6]Agenda Bashing
2. [7]ISSUE-112 - Conformance Models for Usability
3. [8]Face-to-face meetings 2008
4. [9]ISSUE-95 - bookmark APIs
5. [10]ISSUE-96 - Should support for logotypes be a SHOULD or a
MAY?
6. [11]ISSUE-103 - How should unknown CAs and self-signed
certificates be treated?
7. [12]ISSUE-106 - We need to define details of cert/URL matching
8. [13]ISSUE-107 - Should there be any recommendations for
https->http form submissions?
9. [14]ISSUE-108 - Should Safe Browsing mode restrict users to a
specific set of sites?
10. [15]ISSUE-109
11. [16]ISSUE-110 - POST triggered via JavaScript
12. [17]Joint session with TAG: Passwords in the Clear
* [18]Summary of Action Items
__________________________________________________________________
<Mez>
[19]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0204.html
<maritzaj> i waslistening to you guys talk about how tlr is hard to
scribe
<ifette> ScribeNick: bill-d
mez agenda bashing - waiting for observers
Agenda Bashing
mez: next f2f
... technical architecture group - tag and password usage in the net
... WSC to help the group move forward with specificatoin
... delay talking about f2f until tlr hal in room
ISSUE-112 - Conformance models for usability
<Mez> [20]http://www.w3.org/2006/WSC/track/issues/112
mez: take on ISSUE-112
maritzaj: mez discussion to move without bruno
... requirements for rejecting or continuing with recomendations - wait
until serge is around to deal with his issues
... issue is conformance page security scores, austin may not suggenst
concrete formula for calculating - recomendation
... some way to decide on how browser should measure issues -
<maritzaj> i'm only hearing about every other word ..
rachana: question on conformance vs recomendation testing -
mez: discussion on how to prove or disprove cause. retest and determine
results
... could considere what kind of usabilty testing should be performed
to be sure they have not been implimented in a way that undercults
usability
rachana: worry that the implimentation does not represent recomendation
... issue is?
mez: guide to determine usability guidelines to the developers who
impliment recomendations
... conformance language, look at language and determine if it is or is
not conformant
rachna: when you MAY MUST SHOULD, negative example must not do X may do
this
... question do we have any MUSTS?
ifette: Must not display favicons or other security infomation in areas
where trust is expected or supposed to be displayed.
PHB: in practice allow must for security issues and then pont to
specific failure - question is it testable?
ifette: google is being taken to court because advertisements are not
seperated from searches - is it testable?
mez: useability is not tied to conformance an musts. is it expectations
or best practices
ifette: areas that of chrome and text noted as MUST and not be able to
test
<Mez> [21]http://www.w3.org/TR/wsc-xit/
mez: looking at document to look for text and language of
recomendations - e.g. MUST
<ifette> [22]http://www.w3.org/2006/WSC/drafts/rec/#techniques-dontmix
ifette: in doc - favacon is not expected to display trust
rachana: section 8.3.2 third bullet
ifette: execute docs outside of browser environment - user is not
informed.
PHB: not running of the code, installation of the code is important
rachana: you must get user consent and inform the user is very hard to
get done.
mez: attempt to inform the user - MUST attempt...
... conformance language will not have effectiveness
<Mez> [23]http://www.w3.org/2005/Security/wsc-charter
<Mez> The goal of this Working Group is to enable users to come to a
better understanding of the context that they are operating in when
making trust decisions on the Web
phb: SMINE - applications must provide protection of private key - does
not say how, many ways to do it.
<Mez> A W3C Recommendation that specifies a minimal set of security
context information to be made accessible to users, and best practices
for the usable presentation of this information;
<Mez> a W3C Recommendation that specifies techniques that render the
presentation of security context information more robust against
spoofing attacks.
rachana: dont think we should weaken it - must inform the user,
implementation does not conform
<ifette> I just created ISSUE-131 to track my issue with code outside
of the browser...
<ifette> [24]http://www.w3.org/2006/WSC/track/issues/131
phb: be able to turn off-on specific plug-ins for specific sites
mez: back to ISSUE-112 conformance language and concrete notion
<rachna> I don't think we should weaken "Must inform" to "attempt to
inform". If the system informs the user, it conforms. If it does not
inform the user, it is non-conforming.
ifette: need user testing to determine viability
rachana: show that you have informed user
tlr:generally, w3c does not test conformance
... however, if vendor asserts and doesn't actually conform, then
that's a matter for law enforcement ...
phb: ftc only gets involved with issues like malware software folks -
remove software - does not.
... good faith issue, company like IBM user conformance language is
expect app to work correctly
rachana: dispute what conforms
phb: need usability because we don't have engineering
rachana: if you don't have data to back up results no one will accept
it
mez: to tlr - does this come up with other wgs
<Mez> if we want to break during the official time period, we need to
in 1 minute
<Mez> if we want the full 30 minutes of coffee
tlr: accessabiliy folks are being referenced by law - conformance needs
to be validated
hal: SAML must pass liberty alliance testing
<Mez> maritza, would you be wiling to take the next 30 minutes to
summarize and propose next steps forward on this issue?
<maritzaj> sure
<tlr> [25]http://www.w3.org/TR/mobileOK-basic10-tests/
mez: time to get started - maritzaj are you available?
<maritzaj> yep ... is the phone up?
<Mez> martiza, you ready to restart?
<maritzaj> calling in now
<maritzaj> should i talk louder?
maritzaj: issue what to display security info primary chrome, secondary
chrome
<maritzaj> [26]http://www.w3.org/2006/WSC/wiki/SharedBookmarks
<Mez> what is the title?
maritzaj: ones we are not implementing we should give simular feedback
- bullet 5 types of things that should give suggenstions on how to
resolve
<maritzaj> What do they indicate?
<maritzaj> by lorrie cranor
<Mez> this one
<Mez>
[27]http://portal.acm.org/citation.cfm?id=1125890&jmp=cit&coll=portal&d
l=ACM&CFID=514855545&CFTOKEN=514855545#CIT
<Mez> I do not
maritzaj: access to link needs ACM access
<ifette> I have access to the link
<ifette> works fine for me
<ifette> (yay vpn)
<Mez> right, you or someone else paid
<ifette> (google)
maritzaj: asking rachana if it was what she though
tlr: notes w3c specific tests within mobile web effort - link listed
earlier
mez: what are next steps, if none can it be closed
maritzaj: should it be on hold until it is clear
<maritzaj> link?
<tlr> [28]http://www.w3.org/TR/wsc-xit/#sec-conformancenote-usability
<maritzaj> thx
tlr: notes that problem is on table in concrete way -
... usability and robusteness may still be built out - here is testing
and guidance to do testing
mez: asks can this be done
<tlr> Web User Agents MUST NOT display material controlled by Web
content in parts of the user interface that are intended or commonly
used to communicate trust information to users.
<ifette> (what is "this")
<ifette> (irc notes not clear)
rachana: seperation of recomendation and conformance - conformance
language notes MUST and comliance to MUST
... best that can be done is provide guidelines and previous studies
tlr: run test with following properties, mobile locate does for web
sites the parameters and requiring test
mez: low bar conformance claim must specify ...
... points back to mobile effort
... ifette disagree -
ifette: throw out results because does not agree with test that were
developed and run
<Zakim> Mez, you wanted to say that performance tests are like that too
mez: utility is that early conformance testing was rigged to provide
results that were desired
... conformance testing is now based on standards testing
<Zakim> PHB, you wanted to say that it is accepted that usability tests
have a subjective quality but
ifette: this is what you have to test and this his how it should be
tested
<maritzaj> maybe we should put this issue on hold until we've designed
the test plans for the recommendations we will test, have a clear idea
what all our recommendations will be ( after we decide on the
elimination process/criteria) and use both of these to decide if we
need to set usability requirements of someone else's instance of our
recommendation
phb: somewhat subjective now, should change over time to me more
accurate, remove testabiliy statement where we have MUST
ifette: does not think conformance testing should should be traken on
when it can be scientific
rachana: test is accurate if 3rd party can repeate iit
ifette: tests are not repeatable
tlr: must trust statistics, describe test in a way where results are
obtainable
phb: interoperabilty test - only test a tiny number of states or formal
proofs - must allow for imperfections and quality of tests.
... not trying to do things in a completely proven manner
ifette: how can it best be constructed guidance and clarity to the
process
mez: straw poll if we agree disagree - abstain continuing to pursue 112
and language around conformance
<tlr> let's pursue it
mez: or not worth our time
<ifette> disagree
<Mez> agree
<hal> agree
agree
<rachna> agree, we have to address this somehow
<maritzaj> agree
<PHB> abstain
<yngve> abstain
<luis> yes
mez: majority of votes to continue to look into the issue
<tlr> ACTION: fette to clarify requirements for usability testing for
conformance by e-mail [recorded in
[29]http://www.w3.org/2007/11/06-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-330 - Clarify requirements for usability
testing for conformance by e-mail [on Ian Fette - due 2007-11-13].
maritzaj: look for issue that ifette can use to develope language
<tlr> ACTION: maritza to work toward worked example of usability
testing for conformance [recorded in
[30]http://www.w3.org/2007/11/06-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-331 - Work toward worked example of
usability testing for conformance [on Maritza Johnson - due
2007-11-13].
<maritzaj> I have to get to a class ... bye everyone.
<ifette> bye
Face-to-face meetings 2008
mez: Candidates: Google (mountain view) March, Opera (Oslo) May/jun
possibly associated with CABfoum
... Also a work shop about various security aspects
... probably to be hosted on US west coast
... Dave raggett is planning that
ifette: need to check room availability
yngve: latter half of may, early june best
tlr: possible date May 13/14, according to earlier survey of
availablility
<Mez> [31]http://www.w3.org/2006/WSC/track/issues/3
yngve: same week as constitution day (May 17th)
<tlr> ACTION: farrell to elaborate on ISSUE-3 [recorded in
[32]http://www.w3.org/2007/11/06-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-332 - Elaborate on ISSUE-3 [on Stephen
Farrell - due 2007-11-13].
<Mez> [33]http://www.w3.org/2006/WSC/track/issues/4
phb: does not see how FTP affect us, it does not work well with TLS
Mez: Is it out ouf scope or a non-goal
bill-d: How often is FTP used in secure transaction systems?
yngve: mostly used for download
phb/yngve: There is an RFC for FTP/TLS (RFC 4217)
tlr: might be ways to expand document to cover some aspects of FTP over
TLS
<tlr> ACTION: stephen to elaborate on ISSUE-4 [recorded in
[34]http://www.w3.org/2007/11/06-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-333 - Elaborate on ISSUE-4 [on Stephen
Farrell - due 2007-11-13].
tlr: do not want to spend much time on it
ISSUE-95 - bookmark API interactions
<Mez> [35]http://www.w3.org/2006/WSC/track/issues/95
ifette: Not just browser APIs, also affected by new services like
bookmark services like delic.io.us and syncing services
<tlr>
[36]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0188.html
mez: users trust bookmark, content should not be able to add them
<ifette> without user approval
<tyler> So, I'm only catching bits and pieces of this conversation, but
I haven't heard mention of the user driven process for creating a
bookmark. For example, the way the page gets to suggest the bookmark
name.
<ifette> it's called projecting ;-)
<tlr> "the bar" ;-)
tyler: other problem: Somebody gets a bookmark that looks like it is
going to a trusted site
... formeditor will have a bookmark like system to avoid problem
ifette: all this will depend on user habituation
<tlr> ACTION: tlr to propose language on bookmark APIs - due 2007-12-31
[recorded in
[37]http://www.w3.org/2007/11/06-wsc-minutes.html#action06]
<trackbot-ng> Created ACTION-334 - propose language on bookmark APIs
[on Thomas Roessler - due 2007-12-31].
ISSUE-96 - Should support for logotypes be a SHOULD or a MAY?
<Mez> [38]http://www.w3.org/2006/WSC/track/issues/96
ifette: summary: jonath saying that it should be a MAY due to the fact
that the extension has no standardized vetting procedure yet, but
should raise attention about it
<ifette> I would suggest a straw poll if we want forward motion
<tlr> mez: so i hear secondary is a should, and primary is still in
discussion
<tlr> ... let's leave it there for the FPWD
<tlr> (that was MEZ's summary)
phb: recolletion of austing discussion: two tiers if you display it you
MUST do it right
second tier: Issuers should be able to check their own logo
yngve: what does MAY really mean?
<ifette> ifette: Straw poll might be best as 3-way poll: Should
anything be said at all / should we say MAY / should we say SHOULD
<tlr> [39]http://www.w3.org/TR/wsc-xit/#signal-content
luis: displaying logotype is a MAY, but when displaying the form it is
displayed is MUST
<Mez> For Web user agents that use a visual user interface capable of
displaying bitmap graphics, during interactions with a TLS-secured Web
page for which the top-level resource has been retrieved through a
strongly TLS-protected interaction that involves an extended validation
certificate, the identity signal [[MAY | SHOULD]] include display of an
[[issuer | community | subject]] logotype that is embedded in the
certificate using the logotype extension [RFC3709].
phb: We must tell people they must not implement logotypes badly
<Mez> straw poll:
<Mez> 1) insist on SHOULD
<Mez> 2) think MAY is fine
<Mez> 3)want to yank the whole sentence
phb: logotypes is oldest related spec not having been adopted
<Mez> 4) abstain
<tyler> Are the "people" certificate issuers or browser implementers?
<PHB> 2) Insist on MAY
<PHB> 1.5) Accept MAY, prefer SHOULD
<PHB> OK take out 4
<PHB> OK take out 3
option 2
<Mez> 1) Prefer SHOULD
<Mez> 2) Prefer MAY
<Mez> 3) Yank the sentence
<Mez> 4) Abstain
<PHB> Option 1 then
ifette: phb suggested adding guidelines for how to implement logotypes
when displaying them
<Mez> yes I did zakim
<tlr> 1. Yank the sentence?
<tlr> 2. Keep it with SHOULD or MAY?
<tlr> 3. Abstain
<Zakim> ifette, you wanted to raise phishing meta point for later
<Zakim> rachna, you wanted to ask about effectiveness
rachna: should find out if logotypes work during prototyping, before
deciding MAY/SHOULD
<tyler> Who's driving the logotypes proposal?
<Mez> I think Phil, but just a guess
<tyler> So it seems like that person should get an ACTION to provide a
detailed proposal that our usability gurus can evaluate.
<Mez> to quote Daffy Duck, "Pronoun problems."
phb: It is easy to verify logos for major brands, more difficult for
less known brands
mez: sounds like there is not enough information from experts available
for usability testers
<Mez> "we're going to collect some hard data" - not to self, ask phb
who we is
<tyler> It seems this issue is on the threshold of being "New security
information" <[40]http://www.w3.org/TR/wsc-usecases/#vaporware>
ifette: need representative sample of sites with and without logotypes,
and discover user decision processes
<tlr> ACTION: ifette to outline discussion topics for ISSUE-96
[recorded in
[41]http://www.w3.org/2007/11/06-wsc-minutes.html#action07]
<trackbot-ng> Created ACTION-335 - Outline discussion topics for
ISSUE-96 [on Ian Fette - due 2007-11-13].
<ifette> ifette: Need an idea for what percentage of sites in the wild
we expect to be using certs with logos
<ifette> ack
<Zakim> ifette, you wanted to raise phishing meta point for later
ifette: talks about things in terms of phising, what about the next big
problem,must avoid tunnel vision
<tlr> mez: we are putting off the strawpoll
ISSUE-103 - How should unknown CAs and self-signed certificates be treated?
<Mez> [42]http://www.w3.org/2006/WSC/track/issues/103
<tlr> [43]http://www.w3.org/2007/10/03-wsc-minutes.html#ISSUE-103
ifette: what is the current difference, if any?
... misread issue
phb: should not treat selfsigned better than something with a
certification path
ifette: listed choices are not close to what I want
<Zakim> Mez, you wanted to say self signed important in walled gardens;
can be "better" for use cases
<ifette> ifette: I don
<ifette> ifette: I don't really understand the limitation of the
choices. I'm happy to treat self-signed the same as unknown CA, where
are all the choices coming from
Mez: Trust IBM intranet certificates
tlr: last time we seemed to agree they should be handled similarly, but
were exploring some differences
<Mez> buffer overflow
<tyler> +1
tlr: form editor is almost entirely concentrated on the public keys
... we have an action for this issue assigned to tlr
hal: actual issue: What should be the handling of these certificate.
... two possibilities:may decide two cases are so similar for a user
that we handle them the same, alternatively may decide they need
separate handling
decision was to rename issue to better description
ISSUE-104 - Some information in certificates is not trustworthy
Some discussion about which fields can be trusted and how to decide
tlr: no usable way to decide if most items in the subject field is
trustworthy
<tlr> [44]ACTION-318 reassigned to Bill Doyle
<ifette> what's the next issue?
ISSUE-106 - We need to define details of cert/URL matching
<tlr> ACTION: farrell to propose material for ISSUE-106 [recorded in
[45]http://www.w3.org/2007/11/06-wsc-minutes.html#action08]
<trackbot-ng> Created ACTION-336 - Propose material for ISSUE-106 [on
Stephen Farrell - due 2007-11-13].
ISSUE-107 - Should there be any recommendations for https->http form
submissions?
<Mez> [46]http://www.w3.org/2006/WSC/track/issues/107
yngve: Some cases like passwords and credit card details are
problematic
ifette: webmaster knows best what is sensitive
yngve: creditcard example was due to misconfiguration that slipped
through because not client warned about it
<tlr> ACTION: rachna to prod serge about SSL error study; re ISSUE-107
[recorded in
[47]http://www.w3.org/2007/11/06-wsc-minutes.html#action09]
<trackbot-ng> Created ACTION-337 - Prod serge about SSL error study; re
ISSUE-107 [on Rachna Dhamija - due 2007-11-13].
ISSUE-108 - Should Safe Browsing mode restrict users to a specific set of
sites?
<tlr> [48]http://www.w3.org/TR/wsc-xit/#usage-sbm
<Mez>
[49]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0082.html
tlr: Too many unresolved variables in current language about SBM
phb: same comments as for logotypes apply here
<tlr> ACTION: hallam-baker to prepare discussion topics for Safe
Browsing Mode; see ISSUE-108 [recorded in
[50]http://www.w3.org/2007/11/06-wsc-minutes.html#action10]
<trackbot-ng> Created ACTION-338 - Prepare discussion topics for Safe
Browsing Mode; see ISSUE-108 [on Phillip Hallam-Baker - due
2007-11-13].
<PHB> PHB: I don't want anything as powerful as a browser for the
limited modes of interaction that I see as appropriate for
exceptionally sensitive data
<PHB> PHB: Passwords, credit card data etc should ideally be managed by
a separate console managed deep inside the O/S kernel
<PHB> PHB: That is much much lss than a browser.
<PHB> Favicons, favi-CONNED!
ISSUE-109
Mez: want meta points for discussion
ISSUE-110 - POST triggered via JavaScript
<luis> [51]http://www.w3.org/2006/WSC/track/issues/110
tlr: http spec assumes unsafe methods like POST are only submitted as a
result of user interaction
phb: Add these actions/methods to sandbox
tlr: xforms have unattended POSTs in use
... getting unattended POSTs under control may be futile
<tlr> Web Application Formats, Forms, HTTP
<PHB> OK if Don Quihote doesn't feel like jousting today...
<ifette> Ik ga nu aan de luchthaven weg. KL6547 neemt me naar
Minneapolis.
<Mez> [52]http://en.wikipedia.org/wiki/Rabbit_Seasoning
yngve: suggest that authoring recommendations say websites MUST NOT
send sensitive data, like creditcard information, using automatic
Javascript actions, unless the action is triggered by positive action
by the user
<tlr> ACTION: yngve to propose authoring best practice for ISSUE-110
[recorded in
[53]http://www.w3.org/2007/11/06-wsc-minutes.html#action11]
<trackbot-ng> Created ACTION-339 - Propose authoring best practice for
ISSUE-110 [on Yngve Pettersen - due 2007-11-13].
Passwords in the clear (joint session with TAG)
<Mez>
[54]http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.html
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0027.html
<tlr> [55]http://lists.w3.org/Archives/Public/www-tag/2007Jun/0130.html
<Mez>
[56]http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.html
<tlr> [57]http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
<Mez>
[58]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0027.html
Introductions (see attendee list)
<Mez> or why can't you just say the part that's easy?
Stuart: why is it so hard to say that sending passwords in the clear is
bad
<Mez> [59]http://lists.w3.org/Archives/Public/www-tag/2007Jun/0130.html
<Mez> is the ref tyler
<Mez> he's speaking to that
Concentrating on #3
Henry: problem is that we can't tell people not ot do this
?? Problem was that people said that there are cases where low security
is acceptable: eg putting pictures on the web
MEz(jumps Q0: People use passwords for multiple sites
<tlr> phb: security not about risk elimination
<tlr> ... in terms of significant concerns ...
<tlr> ... passwords from the wire is the least case of concern to me
...
<tlr> ... in particular because even if you encrypt the password ...
<tlr> ... unless you use SSL transport, there's no protocol today that
provides adequate security against brute force ...
<tlr> ... and is unencumbered ...
<tlr> ... there are various tweaks to resist bruce force attacks ...
<tlr> ... they're all encumbered ..
<tlr> ... if we say "this is ok for weak protection" ...
<tlr> ... if you're using passwords, don't expect to use them beyond
weak protection ...
<tlr> ... ten years ago, there was a reason to make that kind of
statement ...
<tlr> ... when the IETF made the statement ...
<tlr> ... but currently, there's nothing unencumbered that provides
adequate security ...
Henry: hears two differewnt things from people sitting next to each
other
MEZ: they are reconcilable
Henry: Are you saying TAG pronouncement would be worse than useless?
<tyler> Good Practice: Use SSL when transmitting sensitive information
<tlr> phb: wordsmithing a statement at this time is too late
<tlr> ... move beyond passwords ...
<tlr> ... look at technologies like federated identity, saml, openid
...
<tlr> ... so instead of giving out the same password to multiple sites
on the web ...
<tlr> ... can give password exclusively to authentication service ....
<tlr> ... then use that service for secure connection ...
<tlr> ... if I go to disreputable.com, use digest Auth over SSL ...
<tlr> .... they can then brute force my password ...
<tlr> ... and go to the other sites where I've used that password ..
Noah: Can understand how people using simple passwords are vulnerable
to brute force.. what if I choose a strong one?
<tlr> pbaker: Several 100 username / password pairs. No way I can
remember all of them usefully
<tlr> ... therefore, share ...
<tlr> ... today, home PC has 10 × power of Cray 1 ...
<tlr> ... botnets are massively parallel computers ...
<tlr> ... computing power doubling every 18 months ...
<tlr> .... that means you have to add another character to password
every 4 years ...
<tlr> ... if we want same level of password strength today as 1992,
when we discovered 7 char were insecure ...
<tlr> ... then we would need 12+ characters today ...
Rachna: echos' PHB's point that strong passwords are simply not
memorable
<tlr> rachna: Google has statistic that 50% of their users chose from
the same 1e6 passwords
<tlr> ... unless there's technological support, users pick weak
passwords ...
Henry: (recites good practices from draft)
... Can we apply these?
<Mez> TheClear-52Mez.htm
<tlr> [60]http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
Hal: you have four recomendations, there are three on the screen
<tyler> Generalize number 1 from passwords to sensitive information,
and that sounds pretty good
<tyler> The next 3 all have problems in my opinion
<tlr> tyler, q+?
Henry: if we reduce this to just 2, # 2 and 4
... plus an approrpriate health warning that passwords are suseptable
to brute force
Hentry: woulf that be of use
Tim: If a password is run over an SSL connection, is that OK
TLR: Issue is that you still disclose to the recipient
Tim: There are cases where people use passwords in the clear when they
don't have to
... can we eliminate them?
... Browser knows a password is being entered because of the blobs,
shouldn't it warn?
<tlr> yngve: 1, 2, 4 useful; 3 is something people disable by default;
we don't do it any more
Yng: ... 3 is moot because every browser now disables it, others are
good idea
Yngve: On email, probably go back to Netscape's dirty flag tracking
password data, to determine if data was originally from a password
field.
Henry: nobody is defending #3 any more
Yngve: Problem is notifying user is going to cause bad reaction because
passwords are used enclair too much
Tyler: In favor of practice #1
... would like to see it generalized
... better to use a self signed cert
... TAG finding to use more SSL would be good
<tlr> pbaker: always in favor of more SSL
<tlr> ... want to be careful about assumption that data entered into
that obscured field is the problem ...
<tlr> ... passwords are only one among many pieces of data that fly
around ...
<tlr> ... best practices for today? ...
<tlr> ... or guide server and browser providers to provide better
infrastructure for future ..
<tlr> ... today, send sensitive data over encrypted link ...
<tlr> ... in 5 years, I'd like people to use sth like Cardspace ...
<tlr> ... today, I have "hallampass" for my NY Times account ...
<tlr> ... minute that ...
<tlr> ... it's the content provider's asset, not mine ...
<tlr> ... don't go for passwords, go for something like Cardspace ...
Dave Orchard: was quing on TAG
Dave Orchard: would be in favor of getting rid of #3 as well, it is the
only one talking about an agent
Dave Orchard: less and less clear wat it means in mashups etc
Tim: Would think that something creative to differentiate secure
password entry from insecure
... SSL and certs have issue that cert may not be issued to the genuine
org so it needs to be checked
MEZ: will you read our first draft
<Zakim> ht, you wanted to explain why I left #1 off
<tlr> person on the phone is Tyler close, HP
HT: Reason I left #1 off was not knowing what it meant
... what is different from #4?
MEZ: #1 is about the network
HT: Thats not how I understood it?
Tyler: I also thought it about the network
Yngve: Server should not present Web form on an insecure page
HT: Server can't know how the form will be submitting
... How does server enforce this
Tim: it sent the document and javascript
<tlr> "server" vs "web application"
HT: recommendation seems to say servers should not send documents that
ask for passwords in the clear... how is Apache to know?
<tyler> "server" => "web application designers"
<Mez> that tyler is one smart cookie
<Zakim> Noah, you wanted to answer Henry
Noah, I have etered a few passwords that would be inconvenient to enter
unmasked.
Noah, addressing HT's question, server means all that is behind the
wire
Noah, someone who wrot the Web page knows that they are asking for a
password
<dorchard> +1 to Noah. It's similar to the definition of "resource"...
<Zakim> tlr, you wanted to also note interaction with mobile devices,
possibly accessibility
tlr: development of web applications
... #4 is a two edged sword
... have seen occasions where bad to have password read, but also entry
on palm is bad without feedback.
<ht> Seems to me that the right resolution of (4) is to say that users
should be given the option to turn masking on and off on a per-entry
basis
<Zakim> tyler, you wanted to clarify between the "server" and the
web-application
tlr: downgrade to a should,
tyler: originally to change server to Web application designer
... users may expect that a password masked on screen is masked on
network
<Mez> weren't there some user studies that showed that such user
expectations existed? or am I making that up?
tyler: this is actually false,
... may be creating false sense security, tag should not make this
recommendation
Yngve: #1 we got, could be an authoring recomendation
... example is places like this
... #4 is relevant to Internet cafes and such
... have settled on solution where last letter entered is not masked.
... Javascript has access to password field
<tlr> phb, it's bookmarklet
<Zakim> dorchard, you wanted to support #4 because just because we've
been successful with #4 doesn't mean we should remove it
Yngve: bookmarklet allows password to be dumpped out
Dave: to champion #4, more shoulder surfing opportunities than we might
think
... how many times have you seen password that isn't masked.
<Mez> and it is so a pain in the neck to change your pword "out of
cycle" if you slip up like that
Dave: All those passwords in the clear... projection screen... all
goodness
<tlr> I disagree that 4 is "all" goodness. It's good in many use cases,
but bad in others.
<tyler> We have to weigh that goodness against the problems with
password masking
Dave: collection of things
<Zakim> PHB, you wanted to say cJust drop 'A server'
<tlr> mez: Can you live with "SHOULD"
<tlr> dorchard: yes
<tyler> I don't think the scales are tilted enough to warrant a finding
<tlr> pbaker: +1 to SHOULD ...
<tlr> ... also, not telling people to look beyond passwords at stuff
that's stronger ...
<tlr> ... that's a disservice ...
<tlr> timbl: reasonable to address situation with existing software
<tlr> ... currently not totally clear to whom it's addressed ...
<tlr> ... with regard to #4 ...
<tlr> ... keep things in proportion ...
<tlr> ... masking passwords is important ...
<tlr> ... if you think it isn't, you don't have teenagers ...
<Mez> +1 to dorchard on the demo thing
<tlr> ... giving presentations ...
<tlr> +1 that it's useful as well, -1 to absolutes for this one
<tlr> ... people might watch and might parse things ...
timbl: people see they are passwords by watching keys
tbl: provide option of unmasking
<Zakim> ht, you wanted to agree with Tyler but make point about user
option
HT: all seem to have ended up in same place
<tlr> ht: leave 4 to WSC
HT: think tyler said, rather than fix #4 we should leave it to WSC
<tlr> ... rather than fix it in TAG ...
HT: Masking, who controls it, etc is complex question
... credit card data is typically not masked, much more serius
<Zakim> rachna, you wanted to ask about adding "by default" to 4
Rachna: you want to leave the hard stuff to us
... ammend 4 to say by defaul agents must/should use password masking
<Zakim> dorchard, you wanted to say that problems with #4 in mobile can
be fixed in, it's just UAs that need work.
dorchard: issue of defaulting is getting us into area of design, better
to go for should
Want simplest message we could in this finding
Lots of different sensitive information, would like to focus on
passwords
<Zakim> Mez, you wanted to mention that 4 is not _necessarily_ in our
charter, explicitly
<Mez> The goal of this Working Group is to enable users to come to a
better understanding of the context that they are operating in when
making trust decisions on the Web; e.g., giving up passwords or other
sensitive information to possibly malicious sites.
Mez, would be nervous that TAG would assume we will deal with #4 if we
do not, have charter to back it,
<Zakim> PHB, you wanted to propose substituting MUST use, SHOULD
support
have issues that might back it if
they don't die
Hal: is possible to prevent keeping password in browsing history
... would suggest these get coded as baest practice
... there is no prearrangement issue
... cannot use digest if your password is stored as a salted hash
<tlr> crypt ("foo", "password") -> "foHgASdfASdfASDf"
Stuart: what is a salted hash
Hal: like what UNIX does
MEZ: password input format assumes that both sides have the secret
yngve: points on #2
<Mez> what's a gpn Noah?
opera will blank a password field on back button
is a problem with the resulting document, is possible to reload it and
get the password resubmitted
<tlr> s/couner/counter/
hal: is there something the browser or whatever can always do?
yngve: solved entry point in page but not the resulting page wich the
server can solve with a redirect
tyler: pick up on the digest hash study
<Mez> no, Die #3, Die!
tyler: pick up on the google study, hash is readily brute forced
... harmful to propose use of digest auth
... if TAG does not propose that more SSL be used on the web here would
be good to see a finding to that effect from the TAG elsewehre
<tlr> pbaker: as primary perpetrator of Digest ..
<tlr> ... it was designed to a specific set of constraints ...
<tlr> ... at the time, PK crypto was encumbered and couldn't be used
...
<tlr> ... looking for best security on the wire ...
<tlr> ... knowing it couldn't be secured on the wire AND at the
destination ...
<tlr> ... reason you couldn't do sth more flexible was specific design
decision ...
<tlr> ... minimize risk of compromise of one site ...
<tlr> ... password hashed to HTTP realm ...
<tlr> ... if you're designing for the web, you don't have a problem ...
<tlr> ... problem occurs when you deal with group that uses same
authentication for web server and Unix box ...
<tlr> ... if you can't recover original user name and password pair,
you're hosed ...
<tlr> ... don't think that's a common use case ...
<tlr> ... it was a use case at CERN, but these days ...
<tyler> Noah, hopefully it leaves them without their sensitive
information sitting in a web cache
<tlr> ... either, Intranet -- do sth like IIS with NTLM digest Webauth
method ...
<tlr> ... IE7 does it ...
<tlr> NT Lan Manager
<tlr> timbl: digestv2?
<Noah> My question was, do we lose scalability if nothing is cacheable.
<tlr> yngve: hmac
<tlr> pbaker: hmac version uses fancier crypto, sha-1 as base for
digest, instead of md5 ...
<tlr> ... md5 is now an unfashionable digest ...
<tlr> timbl: ok, not fundamentally different
<tlr> hal: not addressing the issue ...
<tlr> ... firm corporate policies "you cannot store policies" in many
places ...
<tlr> ... maybe it's not a good policy, but it's common ...
<Noah> I can certainly understand why SSL is the right answer when
information is sensitive, but there is a downside I think to going
further and saying just use SSL most everywhere. I couldn't quite tell
if that was being implied.
<tlr> timbl: back to section 2 -- what is the "password available in
browsing history" doing here?
tbl: issue 2: what is that about?
MEZ: its about caching passwords
<tlr> MEZ: ????
<tyler> Noah, I'm hoping for a finding that recommended use of SSL when
transmitting, or soliciting, sensitive information.
<tlr> tlr: +1 to ???
tbl: its not about sending in the clear, argue it be removed
Yngve: its about having password stored
<tlr> timbl: point 2 should be dropped
tbl: its not about passwords, therefore is out of scope
Noah: what it says is of all the things that you might worry about you
sould be aware of this issue as well,
hal: looks like a residual
Noah: ed was probably thinking that this is a mechanism that can lead
to transmisson of pwd in the clear
tbl: lots of people would come back and say that their ISP would charge
'em more.
Hal: SSL is no longer a performance issue, Wells Fargo have it on
across the board
<Zakim> Noah, you wanted to ask whether we need a GPN explaining the
issues about Digest and salted hashes
Noah: mentioning the digest security thing
<tlr> ACTION: pbaker to gather data about cost of TLS deployment
[recorded in
[61]http://www.w3.org/2007/11/06-wsc-minutes.html#action12]
<trackbot-ng> Sorry, couldn't find user - pbaker
<tlr> ACTION: hallam-baker to gather data about cost of TLS deployment
[recorded in
[62]http://www.w3.org/2007/11/06-wsc-minutes.html#action13]
<trackbot-ng> Created ACTION-340 - Gather data about cost of TLS
deployment [on Phillip Hallam-Baker - due 2007-11-13].
Noah: drift in the room that basic is bad, digest is bad
<tlr> pbaker: deployment problem is same as central password
administration ...
<tlr> ... problem is you don't have RADIUS-style server ...
<tlr> ... and so you shift around the password file ...
<tlr> ... architecturally, you want to outsource password
authentication
<tlr> timbl: ??
<tlr> pbaker: if you do digest as a service, the salting problem is no
problem ...
<tlr> ... if it is *only* for that service.
<tlr> timbl: Thought password has to be on server
<tlr> pbaker: no
<tlr> hal: think you're wrong
<tlr> ... want separate salt for every password ...
<tyler> Just to summarize, the space of user passwords is so small that
hashing does not provide protection
<tlr> noah: ??
<tlr> hal: would like to tell the story about digest
<tlr> pbaker: best is TLS, then using Digest, then basic without TLS
<tlr> ... that's really the worst ...
<tlr> noah: things like akamai?
Noah: taken to its logical conclusion
... To what extent can you say just to use TLS everywhere?
... Data that need not be secured is an important subset
... NYT does ask for a name and a password
... Is there a practical way to cache this?
<Zakim> dorchard, you wanted to ask if any champions for #3?
Dave: wondering how TAG can proceed with this document
Don't think anyone champions #3
Can people live with #4 as a should?
TLR, others: happy, happy happy
Tim: Should we adjust
Mez; no, no, no
publish it d.
Dave: I see the future
Stuart, actionon a tag member
Stuart: action to give action to a TAG member
<tlr> pbaker: it's important to be able to authenticate public data
<tlr> ... TLS isn't the right technology for that ...
<tlr> ... bankrupcy announcements in London Gazette? ...
<tlr> ... right now, rather blow the cache than take that risk ...
<tlr> timbl: sign the data!
<tlr> pbaker: If you're not using an authentication technique, use TLS.
<luis> How is this discussion related to our rec 9.2 "Use of TLS for
Login Pages"
<Zakim> tlr, you wanted to come back to the javascript part at some
point (happy to yield for a while) and to note that there's an
interesting confidentiality vs authenticity question here
Noah: If you havn't got a hammer use a pile driver
PHB: right on
tlr: how is #2 any less turing complete than #1
<Noah> For the record, I was paraphrasing, apparently accurately, what
I took to be Phil's position.
<Mez> please close the queue
HT: If the field is labelled as a password field
... the browser does know.
[Scribe notes injunction from Zakim]
TBL: if you put blodges up to protect the password from soulder surfing
it should go in the clear
correlation between security indicators
<tlr> hal: worried my basic point about digest gets lost
<tlr> ACTION: hal to send message to tag list about digest auth issue
[recorded in
[63]http://www.w3.org/2007/11/06-wsc-minutes.html#action14]
<trackbot-ng> Created ACTION-341 - Send message to tag list about
digest auth issue [on Hal Lockhart - due 2007-11-13].
<Mez> ta tyler
Mez: wrapping
call next week
Put Steve F. on the agenda
TLR: need to adjust due dates
mez: been fun
<scribe> closed
Summary of Action Items
[NEW] ACTION: farrell to elaborate on ISSUE-3 [recorded in
[64]http://www.w3.org/2007/11/06-wsc-minutes.html#action04]
[NEW] ACTION: farrell to propose material for ISSUE-106 [recorded in
[65]http://www.w3.org/2007/11/06-wsc-minutes.html#action08]
[NEW] ACTION: fette to clarify requirements for usability testing for
conformance by e-mail [recorded in
[66]http://www.w3.org/2007/11/06-wsc-minutes.html#action02]
[NEW] ACTION: hal to send message to tag list about digest auth issue
[recorded in
[67]http://www.w3.org/2007/11/06-wsc-minutes.html#action14]
[NEW] ACTION: hallam-baker to gather data about cost of TLS deployment
[recorded in
[68]http://www.w3.org/2007/11/06-wsc-minutes.html#action13]
[NEW] ACTION: hallam-baker to prepare discussion topics for Safe
Browsing Mode; see ISSUE-108 [recorded in
[69]http://www.w3.org/2007/11/06-wsc-minutes.html#action10]
[NEW] ACTION: ifette to outline discussion topics for ISSUE-96
[recorded in
[70]http://www.w3.org/2007/11/06-wsc-minutes.html#action07]
[NEW] ACTION: maritza to work toward worked example of usability
testing for conformance [recorded in
[71]http://www.w3.org/2007/11/06-wsc-minutes.html#action03]
[NEW] ACTION: martiza to work toward worked example of usability
testing for conformance [recorded in
[72]http://www.w3.org/2007/11/06-wsc-minutes.html#action01]
[NEW] ACTION: pbaker to gather data about cost of TLS deployment
[recorded in
[73]http://www.w3.org/2007/11/06-wsc-minutes.html#action12]
[NEW] ACTION: rachna to prod serge about SSL error study; re ISSUE-107
[recorded in
[74]http://www.w3.org/2007/11/06-wsc-minutes.html#action09]
[NEW] ACTION: stephen to elaborate on ISSUE-4 [recorded in
[75]http://www.w3.org/2007/11/06-wsc-minutes.html#action05]
[NEW] ACTION: tlr to propose language on bookmark APIs - due 2007-12-31
[recorded in
[76]http://www.w3.org/2007/11/06-wsc-minutes.html#action06]
[NEW] ACTION: yngve to propose authoring best practice for ISSUE-110
[recorded in
[77]http://www.w3.org/2007/11/06-wsc-minutes.html#action11]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [78]scribe.perl version 1.128
([79]CVS log)
$Date: 2007/11/21 16:06:15 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0204.html
3. http://www.w3.org/2007/11/06-wsc-irc
4. http://www.w3.org/2007/11/06-wsc-minutes.html#Passwords
5. http://www.w3.org/2007/11/06-wsc-minutes.html#agenda
6. http://www.w3.org/2007/11/06-wsc-minutes.html#item01
7. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-112
8. http://www.w3.org/2007/11/06-wsc-minutes.html#Face-to-fa
9. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-95
10. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-96
11. http://www.w3.org/2007/11/06-wsc-minutes.html#item02
12. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-106
13. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-107
14. http://www.w3.org/2007/11/06-wsc-minutes.html#ISSUE-108
15. http://www.w3.org/2007/11/06-wsc-minutes.html#item03
16. http://www.w3.org/2007/11/06-wsc-minutes.html#item04
17. http://www.w3.org/2007/11/06-wsc-minutes.html#Passwords
18. http://www.w3.org/2007/11/06-wsc-minutes.html#ActionSummary
19. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0204.html
20. http://www.w3.org/2006/WSC/track/issues/112
21. http://www.w3.org/TR/wsc-xit/
22. http://www.w3.org/2006/WSC/drafts/rec/#techniques-dontmix
23. http://www.w3.org/2005/Security/wsc-charter
24. http://www.w3.org/2006/WSC/track/issues/131
25. http://www.w3.org/TR/mobileOK-basic10-tests/
26. http://www.w3.org/2006/WSC/wiki/SharedBookmarks
27. http://portal.acm.org/citation.cfm?id=1125890&jmp=cit&coll=portal&dl=ACM&CFID=514855545&CFTOKEN=514855545#CIT
28. http://www.w3.org/TR/wsc-xit/#sec-conformancenote-usability
29. http://www.w3.org/2007/11/06-wsc-minutes.html#action02
30. http://www.w3.org/2007/11/06-wsc-minutes.html#action03
31. http://www.w3.org/2006/WSC/track/issues/3
32. http://www.w3.org/2007/11/06-wsc-minutes.html#action04
33. http://www.w3.org/2006/WSC/track/issues/4
34. http://www.w3.org/2007/11/06-wsc-minutes.html#action05
35. http://www.w3.org/2006/WSC/track/issues/95
36. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0188.html
37. http://www.w3.org/2007/11/06-wsc-minutes.html#action06
38. http://www.w3.org/2006/WSC/track/issues/96
39. http://www.w3.org/TR/wsc-xit/#signal-content
40. http://www.w3.org/TR/wsc-usecases/#vaporware%3E
41. http://www.w3.org/2007/11/06-wsc-minutes.html#action07
42. http://www.w3.org/2006/WSC/track/issues/103
43. http://www.w3.org/2007/10/03-wsc-minutes.html#ISSUE-103
44. http://www.w3.org/2006/WSC/track/actions/318
45. http://www.w3.org/2007/11/06-wsc-minutes.html#action08
46. http://www.w3.org/2006/WSC/track/issues/107
47. http://www.w3.org/2007/11/06-wsc-minutes.html#action09
48. http://www.w3.org/TR/wsc-xit/#usage-sbm
49. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0082.html
50. http://www.w3.org/2007/11/06-wsc-minutes.html#action10
51. http://www.w3.org/2006/WSC/track/issues/110
52. http://en.wikipedia.org/wiki/Rabbit_Seasoning
53. http://www.w3.org/2007/11/06-wsc-minutes.html#action11
54. http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.htmlhttp://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0027.html
55. http://lists.w3.org/Archives/Public/www-tag/2007Jun/0130.html
56. http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.html
57. http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
58. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0027.html
59. http://lists.w3.org/Archives/Public/www-tag/2007Jun/0130.html
60. http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
61. http://www.w3.org/2007/11/06-wsc-minutes.html#action12
62. http://www.w3.org/2007/11/06-wsc-minutes.html#action13
63. http://www.w3.org/2007/11/06-wsc-minutes.html#action14
64. http://www.w3.org/2007/11/06-wsc-minutes.html#action04
65. http://www.w3.org/2007/11/06-wsc-minutes.html#action08
66. http://www.w3.org/2007/11/06-wsc-minutes.html#action02
67. http://www.w3.org/2007/11/06-wsc-minutes.html#action14
68. http://www.w3.org/2007/11/06-wsc-minutes.html#action13
69. http://www.w3.org/2007/11/06-wsc-minutes.html#action10
70. http://www.w3.org/2007/11/06-wsc-minutes.html#action07
71. http://www.w3.org/2007/11/06-wsc-minutes.html#action03
72. http://www.w3.org/2007/11/06-wsc-minutes.html#action01
73. http://www.w3.org/2007/11/06-wsc-minutes.html#action12
74. http://www.w3.org/2007/11/06-wsc-minutes.html#action09
75. http://www.w3.org/2007/11/06-wsc-minutes.html#action05
76. http://www.w3.org/2007/11/06-wsc-minutes.html#action06
77. http://www.w3.org/2007/11/06-wsc-minutes.html#action11
78. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
79. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 21 November 2007 16:12:57 UTC