Meeting record: WSC WG f2f 2007-11-06

Minutes from our meeting on 2007-11-06 were approved and are
available online here:

A text version is included below the .signature.

Thomas Roessler, W3C  <>


                Web Security Context Working Group Face-To-Face
                                   6 Nov 2007


   See also: [3]IRC log


          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

          Amit Parashar, Bede McCall, Dave Raggett


          bill-d, yngve, PHB


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


   <maritzaj> i waslistening to you guys talk about how tlr is hard to

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

   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
   ... could considere what kind of usabilty testing should be performed
   to be sure they have not been implimented in a way that undercults

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

   <Mez> [21]

   mez: looking at document to look for text and language of
   recomendations - e.g. MUST

   <ifette> [22]

   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

   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]

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

   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

   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]

   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

   <maritzaj> [26]

   <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

   <maritzaj> What do they indicate?

   <maritzaj> by lorrie cranor

   <Mez> this one


   <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

   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]

   <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

   <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

   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

   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

   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


   <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

   <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

   <trackbot-ng> Created ACTION-331 - Work toward worked example of
   usability testing for conformance [on Maritza Johnson - due

   <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

   <Mez> [31]

   yngve: same week as constitution day (May 17th)

   <tlr> ACTION: farrell to elaborate on ISSUE-3 [recorded in

   <trackbot-ng> Created ACTION-332 - Elaborate on ISSUE-3 [on Stephen
   Farrell - due 2007-11-13].

   <Mez> [33]

   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

   <tlr> ACTION: stephen to elaborate on ISSUE-4 [recorded in

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

   ifette: Not just browser APIs, also affected by new services like
   bookmark services like and syncing services


   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

   <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

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

   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

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

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

   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

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

   <tlr> [43]

   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

   <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

   <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

   <Mez> [46]

   yngve: Some cases like passwords and credit card details are

   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

   <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

   <tlr> [48]


   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

   <trackbot-ng> Created ACTION-338 - Prepare discussion topics for Safe
   Browsing Mode; see ISSUE-108 [on Phillip Hallam-Baker - due

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


   Mez: want meta points for discussion

ISSUE-110 - POST triggered via JavaScript

   <luis> [51]

   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

   <Mez> [52]

   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

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


   <tlr> [55]


   <tlr> [57]


   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

   <Mez> [59]

   <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

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

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

   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

   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

   Noah, addressing HT's question, server means all that is behind the

   Noah, someone who wrot the Web page knows that they are asking for a

   <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

   <Zakim> tyler, you wanted to clarify between the "server" and the

   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

   <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

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

   <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

   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

   <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

   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

   <trackbot-ng> Sorry, couldn't find user - pbaker

   <tlr> ACTION: hallam-baker to gather data about cost of TLS deployment
   [recorded in

   <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

   <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

   <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
   [NEW] ACTION: farrell to propose material for ISSUE-106 [recorded in
   [NEW] ACTION: fette to clarify requirements for usability testing for
   conformance by e-mail [recorded in
   [NEW] ACTION: hal to send message to tag list about digest auth issue
   [recorded in
   [NEW] ACTION: hallam-baker to gather data about cost of TLS deployment
   [recorded in
   [NEW] ACTION: hallam-baker to prepare discussion topics for Safe
   Browsing Mode; see ISSUE-108 [recorded in
   [NEW] ACTION: ifette to outline discussion topics for ISSUE-96
   [recorded in
   [NEW] ACTION: maritza to work toward worked example of usability
   testing for conformance [recorded in
   [NEW] ACTION: martiza to work toward worked example of usability
   testing for conformance [recorded in
   [NEW] ACTION: pbaker to gather data about cost of TLS deployment
   [recorded in
   [NEW] ACTION: rachna to prod serge about SSL error study; re ISSUE-107
   [recorded in
   [NEW] ACTION: stephen to elaborate on ISSUE-4 [recorded in
   [NEW] ACTION: tlr to propose language on bookmark APIs - due 2007-12-31
   [recorded in
   [NEW] ACTION: yngve to propose authoring best practice for ISSUE-110
   [recorded in

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



Received on Wednesday, 21 November 2007 16:12:57 UTC