Meeting record: WSC WG face-to-face 2008-02-05

Minutes from our meeting on 2008-02-05 were approved and are
available online here:

   http://www.w3.org/2008/02/05-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 Meeting

05 Feb 2008

   See also: [2]IRC log, [3]Agenda

Attendees

   Present
          Thomas Roessler, Mary Ellen Zurko, Serge Egelman, Yngve
          Pettersen, Rachna Dhamija, Tyler Close, Phillip Hallam-Baker,
          Bill Doyle, Maritza Johnson, Hal Lockhart

   Regrets
          Tim Hahn, Ian Fette, Stephen Farrell, Anil Saldhana, Johnathan
          Nightingale, Dan Schutzer, Mike Beltzner, Luis Barriga

   Chair
          Mez

   Scribe
          rachna, bill-d, hal

Contents

     * [4]Topics
         1. [5]Agenda Bashing
         2. [6]Game Plan till June
         3. [7]Identifying Low-hanging fruit
         4. [8]8.3 APIs exposed to Web content
         5. [9]9.3 Use TLS Consistently across the web site
         6. [10]9.2 Use TLS for Login Pages
         7. [11]5.3 Change of security level
         8. [12]6.1 Identity and Trust Anchor Signalling
         9. [13]6.2 Additional Security Context Information
     * [14]Summary of Action Items
     __________________________________________________________________

   <Mez> special thanks to Commercenet for hosting

   <Mez> hal points out the kleenex is a nice touch

Agenda Bashing

   Mez: we will discuss recommendations, ...
   ... then look at mature recommendations ...
   ... and resolve issues in them ...
   ... then what usability testing means for recommendations ...
   ... then process plans on mature recomendations ...
   ... today we'll decide which are mature recommendations...
   ... tomorrow we'll discuss future looking recs ...

   <Mez> [15]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html

Game Plan till June

   Mez: what subset should make it to last call (before our charter ends
   in June)

   tyler: our next document can discuss status quo & what the browsers are
   already doing
   ... I would be surprised if anything not implemented will be a
   recommendation
   ... don't believe a lot of these things will have impact
   ... need user studies

   mez: that's not process so far, you can put this as an issue in tracker

   <tlr> [16]http://www.w3.org/2006/WSC/track/issues/new

   mez: anything that you have a problem with, create an issue using url
   above
   ... make issues well formed

   <Mez> [17]http://www.w3.org/2006/WSC/wiki/WriteGoodIssue

   tyler: there is an implicit issue with all recs that they must provide
   evidence of working

   mez: no not true, it is not implicit- you should raise an issue
   formally

   <Mez> [18]http://www.w3.org/2005/Security/wsc-charter

   <Mez> [19]http://www.w3.org/2006/WSC/wiki/SuccessBaseline

   mez: reviewing success baseline (what makes a successful
   recommendation?)

   tyler: success baseline says demonstrably better

   mez: move to look at recommendations that have few issues

   tyler: we might get more buy in from browser vendors to start with a
   document that describes the status quo

   mez: let's start with recs that are current best practice

   tyler: a document that just introduced nomenclature and status quo
   would be a significant chunk of document

   mez: there are aspects of status quo that we don't address
   ... page security score is the only thing that gets near the padlock
   ... another strategy is to address problems we have with status quo,
   take a look at what else is status quo that we haven't addressed (e.g.
   padlock)
   ... anotehr part of status quo: what to do about urls (the only
   identity signal we have now)
   ... three options for how to address status quo: 1) recommendation
   about 2) we achieve consensus on silence or 3) we don't achieve
   consensus

   tyler: one of benefits of this doc is if you are implementing a new
   browser, you have reference to consult about what everyone else has
   done

   mez: e.g. yes, the mobile platform is an example

   tyler: each new platform/browser team repeats past mistakes

   mez: let's see which recs are status quo, what we have to say about
   status quo and which recs make our cut for being mature

   tyler: do we want to discuss nomenclature?

   mez: let's do recs first, then nomenclature

   tlr: one warning about nomenclature- I merged Stephen's rewrite (what
   is a secure page has been lost)
   ... section 5 changed sustantively

   yngve: I'm coming up with a similar issue re augmented assurance

   <tlr> the secure page thing is in ISSUE-182

   tlr: that section needs another round of review

   yngve: ?

   hal: what is the gameplan after that doc?

   mez: we may need to ask for charter extension

   thomas: my expectation is charter extension

   tyler: on other side of fence, jonathan questions whether it is worth
   proceeding with this group

   <tyler>
   [20]http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-o
   ther-crazy-ideas/

   tyler: one possibility is to document the status quo and call it a day

   hal: how long can we extension?

   thomas: rechartering means changing scope

   <Mez> we will carve out a subset of our recommendations for a document
   that can make last call by June. it will include at least whatever
   recommendations address the status quo for which we have concensus. It
   may include new recommendations on the status quo we have concensus on,
   nomenclature (for that set of recomendations and perhaps beyond), and
   may include other recommendations we have concensus on.

   thomas: extension is w3c decision, can be 3 months, 6 months, there is
   no process inherent limit,...
   ... the limit includes the time for a check point ...
   ... no groups that produce recs are shut down, ...
   ... but are put into hibernation, so you don't lose patent committments
   ...

   mez: creepy

   hal: controversial. agenda du jour blank check.

   tyler: another reason for documenting status quo is usability testing
   is resource intensive

   mez: when I say recommendation, I mean recommendations that we are
   ready to make by June

   tyler: I would like next document on what browsers are doing now

   maritza: these are the recommendations we have that may or may not
   address- this is what we evaluate

   hal: "this is what's on the table"

   phb: anything we recommend is by nature a change

   <Zakim> tyler, you wanted to say recommendations do sometimes document
   current implementation practice

   phb: acceptability is a factor (e.g. browser people push back on
   anything that takes pixels)

   <Mez> [21]http://www.w3.org/TR/wsc-usecases/

   maritza & tyler: talking about coming up with more thorough use
   cases...

   thomas: we are mixing up 3 things: 1) documenting current practice
   (e.g. you can resize windows, which is an anti-pattern)

   2) document best practice (things we endorse)

   <Mez>
   [22]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   3) framework- "here's a way to think about current practice"

   <Mez> I believe this is best current practice, it is robustness, and
   it's ready for lc, imo

   tyler: if we have a doc that is current best practice, can this be a
   recommendation?

   mez and thomas: yes

   thomas: normative language, so there is a notion of conforming and
   non-conforming

   hal: is it worth documenting what is on the table?

   thomas: if there is stuff that we don't want to love, but we don't know
   that we are stopping work on, that can be dropped into a note
   ... we can say that we have a second rec document and produce a working
   draft
   ... there is some things in xit that are being tried in the wild- I
   don't know that everything is in xit

   <tlr> Mez: we will carve out a subset of our recommendations for a
   document that can make last call by June. it will include at least
   whatever recommendations address the status quo for which we have
   concensus. It may include new recommendations on the status quo we have
   concensus on, nomenclature (for that set of recomendations and perhaps
   beyond), and may include other recommendations we have concensus on.

   rachnaconfused by what status quo means

   mez: status quo= practices in use by current web user agents

   thomas: practices for which there is implementation
   ... best current practice= implementation or where we are close to
   having implementation experience

   mez: ssl error messages

   thomas: not sure if browser vendors can claim conformance with all
   language in ssl error section

   <tlr> thomas: but I also think the basic approach is very close

   <Mez> not exactly what I meant, but

   <Mez>
   [23]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-interactivel
   y

   yngve: this is a good practice, this is a bad practice

   <Mez>
   [24]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-certerrors

   tyler: what if we picked a set of user agents and we list things they
   do that is a good idea

   rachna: how about bad ideas?

   tyler: there are too many bad ideas?

   thomas: we are vendor neutral, so we don't want to list them

   tyler: the list doesn't need to be in document

   <Mez>
   [25]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   rachna: what are they doing that we would recommend?

   <tlr>
   [26]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   <tlr> ha, mez beat me to it

   mez: 8.3 robustness, API...

   resolution: go through trees, rather than forest: let's step through
   xit to see what is ready for last call

   thomas: what is reasonable to get to last call (no fundamental
   disagreements)

   mez: yes- no issues logged, or issues can be addressed in a week
   ... what is definition of last call?

   <tyler> I'm going to paste a few that seem like likely candidates for
   Best Current Practice:

   <tyler>
   [27]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-indicat
   or-images

   <tyler>
   [28]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-login-pages

   <tyler>
   [29]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency

   <tlr> Purpose: A Working Group's Last Call announcement is a signal
   that:

   <tlr> * the Working Group believes that it has satisfied its relevant
   technical requirements (e.g., of the charter or requirements document)
   in the Working Draft;

   <tlr> * the Working Group believes that it has satisfied significant
   dependencies with other groups;

   <tlr> * other groups SHOULD review the document to confirm that these
   dependencies have been satisfied.

   <tlr> In general, a Last Call announcement is also a signal that the
   Working Group is planning to advance the technical report to later
   maturity levels.

   <Mez> [30]http://www.w3.org/Guide/

   <Mez> [31]http://www.w3.org/2005/10/Process-20051014/

   <tlr> thomas: rambling from process document

   <tyler> tyler: 8.3 from xit looks like it could be expanded to be a
   useful part of our BCP document

   thomas: there is stuff that is low hanging fruit, where there is
   experience or will be soon, let's go through the doc and see which of
   those we can get to last call by June
   ... there is implementation or implementations that are known to come

   rachna: what about implementations we do?

   mez: we are the public

   <tlr> So resolved.

Identifying Low-hanging fruit

   <Mez> there is stuff that is low hanging fruit, where there is
   experience or will be soon, let's go through the doc and see which of
   those we can get to last call by June

   <Mez> 8.3

   mez: we can take one at a time, full list or partial list

   <serge> are we there yet?

   <Mez> there is stuff that is low hanging fruit, where there is
   experience or will be soon, let's go through the doc and see which of
   those we can get to last call by June

   <Mez>
   [32]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   <tlr>
   [33]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange

   mez: directed to Serge, whatever recommendations we have for what works
   well for errors needs to go in doc

   <Mez> spend time fleshing out 8.3

   <Mez> 9.1

   <Mez> 9.2

   <Mez> 9.3

   <Mez> all of 9

   <Mez> 5.3

   <Mez> 7.9

   <Mez> 4.2

   <Mez> all of 8

   <Mez> section 5

   <Mez> 5.1.2

   <Mez> 7.8

   <Mez> 8.2

   <Mez> 6.1

   <Mez> 6.4

   <Mez> 5.2

8.3 APIs exposed to Web content

   <Mez>
   [34]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   <Mez> [35]http://www.w3.org/2006/WSC/track/issues/95

   <tlr>
   [36]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0233.html

   tyler: browser's inability to prevent applications from obscuring
   browser content

   <Mez> [37]http://www.w3.org/2006/WSC/track/issues/131

   <Mez>
   [38]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0246.html

   ??problem with whack-a-mole attack

   phb: rename whack-a-mole attack

   rachna agrees that wahck-a-mole is not a technical attack name

   <Mez>
   [39]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#whack-a-mole

   mez: can someone propose a name?

   <PHB> I suggest user control hijacking attack

   <Mez> user control highjacking attack

   <serge> how about Attack #894875/A ?

   <Mez> window popup attack

   <Mez> simon sez attack

   <Mez> click through attack

   <Mez> interaction flooding attack

   mez: proposal change text of whack s mole to "interaction flooding
   attack"

   <Mez> rachna: what is the scope for the defn of this section?

   <Mez> ... if a cert error dialog pops up, these extensions will prevent
   the dialog will pop up

   <Mez> tlr: they are part of the ua

   <Mez> rachna: this only applies to content

   <Mez> tlr: a web page shouldn't be able to make that happen

   <tlr> Web user agents MUST prevent web content from obscuring, hiding,
   or disabling security UI.

   <tlr>
   [40]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirements-rob
   ustness

   <tlr>
   [41]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#definitions

   tyler: second bullet under 8.3.1. are active X controls outlawed under
   this?

   mez: active x controls are installed, user interaction is required if
   signature is not trusted

   thomas: we elaborate on what constitutes software download

   rachna: summarizing my concern from earlier... 8.3 should not cover
   user agents that prevent the display of SSL warning messages

   phb: what about interactions that allows you to say all active x
   controls from this provider can run?
   ... don't want to have a "must" that requires users to individually
   agree to each activx control, rather than agreeing to all active X
   controls from one provider (e.g. Microsoft)

   bill: this applies to the language about "allowing users to preconsent"

   tyler: if a browser that comes shipped with pre-installations that does
   not ask for preconsent is not compliant?

   phb: what if you ship a trusted configuration of browser
   (pre-configured) version of browser?
   ... some extensions are pre-configured, while other extensions are
   "after market". Our document does not distinguish between the two.

   mez: if you shipped as part of browser, is it the browser or an
   extension to the browser?
   ... it is arguable that active x controls don't make a user agent not
   compliant with this section (only violating MUSTS, not SHOULDS)

   bill: is active x a class you allow?

   <PHB> We need to have a place where we define the term 'extension' as
   opposed to 'component'. A component that ships with the browser is not
   an extension by definition. The browser provider is responsible for the
   browser and all components published with the browser

   tyler: main carve out only covers consent from user. I am pretty sure
   that IE ships with certain certain certs that allow active x controls
   to run without consent from user.

   bill: I don't think that there is any security around a non-signed
   active x control

   <Zakim> PHB, you wanted to point out that it is not user consent that
   is the issue, it is owner of the machine consent

   phb: user is not always the person who has the right to install
   software on the machine. some corporate machines or hospital machines-
   you don't want to allow user to install active x controls.

   mez: nothing in this section allows for policy or system administration
   control - this sounds like a new issue.

   tyler: something we haven't written is that there be away to see what
   user has consented to.

   mez: do we want to address the fact that pre-configured browsers that
   allow active x to run w/o consent of user

   thomas: addressing phil
   ... addressing phil's issue about pre-configured policies might also
   address the active-x issue
   ... we don't want to disallow corporate policy, global policy that
   might install software without user consent

   <tlr> phb: no software components to be installed without authority

   phb: language should be that "no software can be installed without
   policy. If the policy is to allow the user to set the policy, then user
   consent must be obtained"

   <tlr> If user has authority, then don't presume .. $( insert current
   text here )

   tyler: what do mean by execution of privileged code?
   ... priviledged code would include API for reading files (hal: reading
   specific files)

   phb: we don't have a good boundary for what is privileged.

   thomas: there is in commonly deployed browsers a user expectation that
   "I have stuff on my machine that I interact with normally that is not
   affected by my browser"
   ... maybe we need to say that browsers won't change anything outside
   browser

   rachna: this is like saying browsers should be self contained VM

   hal: leaky

   tyler: there isn't a current best practice
   ... we can say we've identified major issue, we'll developing a model
   how installation should be handled

   mez: there are two bullets in 8.3.1. let's consider the first bullet in
   8.3.1.

   thomas: we should separate the bullets in 8.3.1, since they deal with
   two separate issues

   reading 8.3.2....

   tyler: three categories: whack a mole, installation and general
   security guidleines

   phb: understand why interaction flooding attack is mentioned here.
   there must be some control that javascript can only open up a window
   with some user action.
   ... pop-up and pop-under windows ...

   <tlr> [42]http://www.flickr.com/search/?q=padlock&w=all

   <tlr> ... would violate 9.1 as phrased

   <tlr> oooops

   rachna: schemes like SiteKey also violate 9.1

   <tlr> [43]http://www.flickr.com/photos/roessler/107144618/

   <tlr> ScribeNick: bill-d

   <tlr>
   [44]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

   tlr: rewrite of robustness section

   mez: rewrite sections 8.3.1
   ... everyone review

   rachna: issue with third bullet

   mez: normative language lost in translation

   <Mez> Difficult-to-spoof UI elements that cross the chrome-content
   border, such as the anti-phishing warning bubble

   <Mez> [45]http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice

   tyler: technique for alerting is lost in current MUST

   <rachna> the technique being referred to (e.g. firefox anti-phishing
   warning) is about robustness, spoofing and user attention

   mez: third bullet does not belong where it now is, don't know where it
   belongs - robustness?

   tlr: trusted path and user attention

   rachna: harder to obscure

   mez: third bullet could be defense in depth

   rachna: section is about obscuring?

   mez: have to do both of the MUSTs and then two shoulds and should nots
   ... is right place because supports the ability to restrict obscuring
   the secure chrome

   tyler: should have a section that destingishes secure chrome

   <tlr>
   [46]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trust
   edpath

   tlr: it is 8.2

   tyler: crosses chrome content area - prevention of web content can't
   draw it in a way that obscures secure chrome

   tlr: must not let web content paint over, technique for things that are
   supposed to be seperate please use this tequnique for this. trusted
   path, unique chrome contect distinctions.
   ... more 8.2. 8.4 - more combining to secure ui sections

   tyler: move 3rd bullet to establish trusted path

   rachna: trusted path means that the user took some action

   tlr: another rewrite
   ... 8.2. 8.4 and chrome ui - 8.3 cannot paint across boundary
   ... 8.4 split between the two

   rachna: why is the UI attack spelled out specifically?

   mez: just an example

   <tlr> ACTION: thomas to change editor's draft as outlined above
   [recorded in
   [47]http://www.w3.org/2008/02/06-wsc-minutes.html#action01]

   <trackbot-ng> Created ACTION-383 - Change editor's draft as outlined
   above [on Thomas Roessler - due 2008-02-12].

   <tlr> (memo to self: see written notes)

   rachna: don't understand why the specific attack is brought out.

   tlr: causing the user to pause is a way to get user attention
   ... just keep hitting accept until window goes away, user gets used to
   hitting the accept button

   mez: turning 8.3 text to something that eveyone can agree upon
   ... to move forward without waiting for rewrite if nothing surprising
   introduced can the group agree on 8.1

   serge: is secure UI defined?

   mez: what is the problem with text - and how can it be fixed

   serge: any chrome can be security chrome

   tyler: the boundary of the window is security information, bottom strip
   is security ui

   PHB: not our place design, but tell designers how to differentiate

   PHB: each platform or device is going to be different

   rachna: one the designer defines what is secure UI, they need to be
   consistent with it

   mez: place in document that defines secure UI?

   yngve: 4.2.1 - place for it

   tlr: 4.2.1. currently is a place to store info, needs to be built out

   rachna: what about secondary chrome

   mez: seconday is only shown by demand

   serge: should not be able to open browsers without chrome present if
   security info is available

   <rachna> 8.3.1. section does not distinguish between primary and
   secondary chrome (security context info refers to both)

   serge: if we generalize it must be inclusive for all cases

   rachna: serge are you saying developers should never allow secure
   chrome to be over written.

   tlr: if a pop up over writes part of the primary page, is this a
   problem. all secuirty context should be in new windows chrome

   rachna: used by attackers, new windows lacks security info, old window
   is displayed that has security info, users infer that new windows has
   inherited security context

   <rachna> rachna will bring up issue: this section does not address the
   reverse problem where attackers pop up a window that *does not obscure*
   the underlying security context UI. For example, a non-SSL protected
   pop-up window may appear over a SSL-protected page so that the user
   thinks the chrome from the original window applies to the window above
   it.

   serge: if the chrome is not secuirty UI then should not be trusting it

   <Mez> Web user agents SHOULD NOT allow web content to open new windows
   that hide the user agent's chrome.

   mez: would have problems with this if chrome does not have security
   info
   ... is this acceptable

   tlr: maybe we don't want user to see old page and old security
   info.make user believe that new page has inherited security context
   ... , should always be one set of security chrome on the screen - the
   chrome of the current window

   <tlr> distinguish context of window user is interacting

   <tlr> ... with

   mez: take a break get a proposal?

   serge: half baked idea to bind pop-ups to secure chrome. popups can't
   go outside

   <tlr> ACTION: thomas to propose lang about currently interacted primary
   chrome always visible on screen [recorded in
   [48]http://www.w3.org/2008/02/06-wsc-minutes.html#action02]

   <trackbot-ng> Created ACTION-384 - Propose lang about currently
   interacted primary chrome always visible on screen [on Thomas Roessler
   - due 2008-02-12].

   tlr: 8.3.1 tasks to editing the docuemnt the basic requirment is not to
   prevent content from hiding or obscuring - content executiting within
   the window must not turn of or prevent the current primary chrome,
   including APIs
   ... include chrome content boundary - APIs and rephrase in terms of
   general way

   mez: is it possible to rewrite and agree?

   tlr: clarification - on do we believe that group can agree on phrasing?

   tyler: due to spoofing issues, it is a rewrite of section 8 and how
   chrome is being used as a security interface

   mez: two ways to do the painting of pages, goal is chrome not being
   stacked on, distinctive chrome - user to distinguish UI and security
   info

   tlr: suggests certain restrictions on APIs, security bias

   tyrler: have not conqured overhapping issue, includes other browser
   windows. open page in new window including web content

   yngve: opera new window inside the same frame

   hal: differences exist in browsers and presentation of tabbed browsing

   serge: primary window - controls all secutity context - take out
   pop-ups

   tyler: more on - take a look at 9.3

   mez: 8.3.2 banged about a lot. didn't talk about 8.3.3 and 8.4 not run
   to ground

9.3 Use TLS Consistently across the web site

   <tyler>
   [49]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency

   <tlr> ISSUE-162?

   <trackbot-ng> ISSUE-162 -- Recognize there are other forms of network
   security -- OPEN

   <trackbot-ng> [50]http://www.w3.org/2006/WSC/track/issues/162

   mez: is issue 162 the only issue against this?
   ... requires secure login

   tlr: use the same security settings, e.g. ciphers for the entire
   transaction

   <tlr> If a web site requires entry of user credentials, then all
   transactions and presentation based on the user's credentials as well
   as the service provided credential token itself MUST be protected by
   the same level of security.

   <tlr> Servers MUST NOT set credential cookies from secure servers that
   can be sent unencrypted.

   hal: using - lets say tls to protect credentials, is TLS then needed to
   protect all the rest of the data
   ... orginal motive for this is that they encrypt the password and send
   all application data in the clear

   mez: passwords may be reused, another reason for protection req.

   tlr: long term secret, short term secret

   tyler: web application that requests secret MUST alwasy use same level
   of security, derived secret can be at lower level.

   tlr: derived secret can be at the same level and should be protected at
   same level

   mez: need to work on section

   tlr: hopes that tyler has some ideas

   yngve: something can be sent unencrypted it should not have aiuthorizty
   to do sensitive transactions

   tlr: TLS protected - long term, powerful

   <tyler> If a web application solicits a secret, such as a password,
   over TLS, then it MUST always transmit that secret using that same
   level of protection. A secret derived from the TLS protected secret
   SHOULD also be given the same protection. If the derived secret conveys
   as much authority as the original secret it MUST also be protected at
   the same level as the original secret.

   <tlr> works for me

   <hal> Sensitive transactions also MUST be protected using the same
   level of protection.

   If a web application solicits a secret, such as a password, over TLS,
   then it MUST always transmit that secret using that same level of
   protection. A secret derived from the TLS protected secret MUST also be
   given the same protection unless the derived secret conveys less
   authority as the original secret.

   <tlr> f a web application solicits a secret, such as a password, over
   TLS, then it MUST always transmit that secret using that same level of
   protection. Any derived secret that convey a similar level oIf
   authority as the original secret it MUST also be protected at the same
   level as the original secret. Other derived secrets SHOULD also be
   given the same protection.

   <tlr> same level -> at least same level

   <tlr> ACTION: thomas to replace 9.3 by text above [recorded in
   [51]http://www.w3.org/2008/02/06-wsc-minutes.html#action03]

   <trackbot-ng> Created ACTION-385 - Replace 9.3 by text above [on Thomas
   Roessler - due 2008-02-12].

   <PHB> If a web application solicits a secret, such as a password, over
   TLS, then it MUST always transmit that secret using that level of
   protection or better.Any derived secret that convey a similar level of
   authority as the original secret it MUST also be protected at the same
   level as the original secret. Other derived secrets SHOULD also be
   given the same protection.

   mez: replaces text in 9.3

   <tlr> mez: ISSUE-162 moot

   tyler: add clause then sensitive transaction details should also be
   protected by same level of security

   mez: if we have additional issues raise them

   yngve: cookie may not always be associated with the certificate that
   was the basis for the cookie's creation -

   <hal> Sensitive transactions also MUST be protected using the same
   level of protection.

   <tlr> (memo to self: see written notes)

   <tlr> +1 to change

   hal: not dictating what sensitive transaction is

   <Mez> 10 01If a web application solicits a secret, such as a password,
   over TLS, then it MUST always transmit that secret using that level of
   protection or better.Any derived secret that convey a similar level of
   authority as the original secret it MUST also be protected at the same
   level as the original secret. Other derived secrets SHOULD also be
   given the same protection. Sensitive transactions also MUST be
   protected using the same level of protection.

   <tyler> In a web-application, a secret may be used to authorize a
   transaction. The details of that transaction SHOULD also be transmitted
   using the same level of protection afforded the secret itself.

   hal: agrees with mez version

   tlr: merge both tyler and mez versions

   <Mez> a - mez text

   serge: does not like term "sensitive" transaction

   <Mez> b - replace last line of mez text with tyler text

   <Mez> c - concatenate tyler text onto mez text

   <tlr> c

   <Mez> d - abstain

   <maritzaj> A

   <hal> C

   <serge> B, final answer

   <bill-d>c

   <yngve> b

   <tyler> b

   <Mez> d

   <PHB> c

   <tlr> s/phb:c//

   <rachna> c

   <Mez> a - 1

   <Mez> b - 3

   <tyler> Further clarification: For example, a web page which supports
   submission of a request authorized by a secret SHOULD NOT include
   representations that were not transmitted using TLS.

   <Mez> c - 5

   <Mez> d - 1

   <yngve> SSL performance article
   [52]http://boblord.livejournal.com/1538.html

   <Mez> c - 5

   <Mez> b - 3

   <Mez> a - 1

   <Mez> d - 1

   <tlr> ACTION-385: implement option c

   <Mez> I like 5.3 as the next topic

   <Mez> starting at 3:45pm local time

   <Mez> taking other votes though

9.2 Use TLS for Login Pages

   <tyler> I like a variation of 9.2 next. We just said "use MUST use TLS
   consistently". Now let's say, "You SHOULD use TLS"

   <tyler> I like a variation of 9.2 next. We just said "you MUST use TLS
   consistently". Now let's say, "You SHOULD use TLS"

   <tyler> An author MUST NOT create a web page which mixes
   representations served using TLS with representations that are not
   served using TLS.

   <tyler> An author MUST NOT create a web page which mixes
   representations served using TLS with representations that are not
   served using at least that level of protection.

   <tyler> An author MUST NOT create a web page which mixes
   representations served using TLS with other representations that are
   not served using at least that level of protection.

   <tyler> I think the above text is an implied consequence of the text
   that Hal proposed and we just voted on. I think the above text should
   be included in addition.

   <tyler> An author MUST NOT create a web page served using TLS that
   includes other representations that are not served using at least that
   level of protection.

   <tyler> An author MUST NOT create a web page served using TLS that
   includes other representations not served using at least that level of
   protection.

   <tyler> I think the above text is an implied consequence of the text
   that Hal proposed and we just voted on. I think the above text should
   be included in addition.

   <tyler>
   [53]http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-o
   ther-crazy-ideas/

   <tyler> Web page authors SHOULD use TLS, or similar protection, to
   protect transmission of secrets.

   <tyler> Web page authors SHOULD use TLS, or similar protection, to
   protect transmission of secrets, such as passwords.

   <tyler> Web page authors SHOULD use TLS, or similar protection, to
   protect both the transmission and solicitation of secrets, such as
   passwords.

   <tlr> Login page must be authenticated / integrity protected using TLS
   or similar protection; password that's returned needs privacy
   protection using TLS or similar protection.

   <tlr> "needs" = "MUST"

   <tlr> or, "SHOULD"?

   <tlr> Web pages SHOULD use TLS to protect the privacy of secrets, such
   as passwords, in transmission. If passwords are submitted in this way,
   solicitationi pages MUST be authenticated and integrity protected using
   TLS or similar techniques.

   <yngve> A web service that solicits a secret transmitted using TLS
   protection, MUST solicit that secret from a TLS protected form. A
   non-TLS protected page MAY carry a link for the user to click to be
   taken to a TLS protected page to enter login information. This link
   MUST NOT carry a padlock along with it

   <tlr> Web pages SHOULD use TLS or comparable mechanisms to protect the
   privacy of secrets, such as passwords, in transmission. If secrets are
   submitted in this way, solicitation pages MUST be authenticated and
   integrity protected using TLS or comparable techniques.

   <tlr> (note to self: look for better words instead of "solicitation
   pages"

   <tlr> )

   <tlr> ACTION: thomas to update 9.2 with statement above [recorded in
   [54]http://www.w3.org/2008/02/06-wsc-minutes.html#action04]

   <trackbot-ng> Created ACTION-386 - Update 9.2 with statement above [on
   Thomas Roessler - due 2008-02-13].

   <tlr> solicitation -> secret solicitation (editorial)

   <Mez> 10 01Web pages SHOULD use TLS or comparable mechanisms to protect
   the privacy of secrets, such as passwords, in transmission. If secrets
   are protected in this way, solicitationi pages MUST be
   cryptographically authenticated and integrity protected using TLS or
   similar techniques.

   <Mez> Web pages SHOULD use TLS or comparable mechanisms to protect the
   privacy of secrets, such as passwords, in transmission. If secrets are
   protected in this way, solicitation pages MUST be cryptographically
   authenticated and integrity protected using TLS or similar techniques.

   <PHB> Web pages SHOULD use AUTHENTICATED TLS ....

   <PHB> Where authenticated means either trusted cert or a self signed
   that is explicitly trusted

   <Mez> 04 01Web pages SHOULD use authenticated TLS or comparable
   mechanisms to protect the privacy of secrets, such as passwords, in
   transmission. If secrets are protected in this way, solicitation pages
   MUST be cryptographically authenticated and integrity protected using
   TLS or similar techniques.

   <Mez> [definition: Autenticated TLS means either using a trusted cert
   or a self signed that is explicitly trusted]\

   <serge> Web pages SHOULD use TLS or comparable mechanisms to protect
   the privacy of secrets, such as passwords, in transmission. If secrets
   are protected in this way, solicitation pages MUST be cryptographically
   protected.

   <PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
   to protect the privacy of secrets, such as passwords, in transmission.

   <PHB> definition: Autenticated TLS means either using a trusted cert or
   a self signed that is explicitly trusted

   <Mez> [55]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls

   <PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
   to protect the confidentiality of secrets, such as passwords, in
   transmission.

   <PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
   to protect solicitation pages for secrets.

   <Mez> 10 01Web pages SHOULD use authenticated TLS or comparable
   mechanisms to protect the confidentiality of secrets, such as
   passwords, in transmission.

   <Mez> If secrets are protected in this way, 10 01web pages SHOULD use
   authenticated TLS or comparable mechanisms to protect solicitation
   pages for secrets.

   <Mez> definition: Autenticated TLS means either using a trusted cert or
   a self signed that is explicitly trusted

   <Mez> 10 01Web pages SHOULD use authenticated TLS or comparable
   mechanisms to protect the confidentiality of secrets, such as
   passwords, in transmission.

   <Mez> 01If secrets are protected in this way, 10 01web pages MUST use
   authenticated TLS or comparable mechanisms to protect solicitation
   pages for secrets.

   <Mez> 01definition: Autenticated TLS means either using a trusted cert
   or a self signed that is explicitly trusted

   <tyler> Web page authors SHOULD use TLS, or similar protection, to
   protect both the transmission and solicitation of secrets, such as
   passwords.

   <Mez> Web pages SHOULD use authenticated TLS or comparable mechanisms
   to protect the confidentiality of secrets, such as passwords, in
   transmission.

   <Mez> Web pages SHOULD use TLS or comparable mechanisms to protect the
   confidentiality of secrets, such as passwords, in transmission.

   <tyler> Web page authors SHOULD use TLS, or similar protection, to
   protect both the solicitation and transmission of secrets, such as
   passwords.

   <tlr> also, it's not web page authors, but I consider that an editorial
   question...

   <Mez> Web sites SHOULD use TLS, or similar protection, to protect both
   the solicitation and transmission of secrets, such as passwords against
   disclosure to unauthorized parties..

   <Mez> Web page authors MUST use TLS, or similar protection, to protect
   both the solicitation and transmission of secrets, such as passwords.

   <serge> PHB: so then you're forced to pay ~$20/yr to use your own file
   server securely?

   <tlr> Web pages SHOULD use TLS, or similar protection, to protect both
   the solicitation and transmission of secrets, such as passwords,
   against disclosure to unauthorized parties.

   <Mez> Web pages MUST use TLS, or similar protection, to protect both
   the solicitation and transmission of secrets, such as passwords,
   against disclosure to unauthorized parties

   <PHB> MUST

   <Mez> a - should

   <tlr> MUST

   <Mez> b - must

   <serge> MUST

   <Mez> c - abstain

   <maritzaj> should

   <PHB> b

   <tyler> a

   <yngve> a

   <tlr> b

   <rachna> must

   <hal> must

   <Mez> abstain

   <Mez> should/a - maritzaj, tyler, yngve

   <Mez> must/b - phil, thomas, serge, rachna, hal

   <Mez> abstain - mez

   <bill-d^gt; a

   <tlr> tyler: will change toward "must"

   <tlr> mez: fine

   <tlr> resolved: MUST

   <Mez> Web pages MUST use TLS, or similar protection, to protect both
   the solicitation and transmission of secrets, such as passwords,
   against disclosure to unauthorized parties

   <tlr> ACTION-386 refers to *this* text.

   <tyler> An author MUST NOT create a web page served using TLS that
   includes other representations not served using at least that level of
   protection.

5.3 Change of security level

   <Mez>
   [56]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange

   <tlr> ISSUE-114?

   <trackbot-ng> ISSUE-114 -- Self-signed certificate changeover -- OPEN

   <trackbot-ng> [57]http://www.w3.org/2006/WSC/track/issues/114

   <Mez> users should be able to visit a site protected by a self signed
   certificate

   <Mez> users should not be told that a site protected by a self signed
   certificate is trustworthy [absent additional information]

   <tlr> [58]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#weak-tls

6.1 Identity and Trust Anchor Signalling

   <tlr>
   [59]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content

   <tlr> During interactions with a Web page for which any of the
   resources involved was retrieved through a weakly TLS-protected
   transaction, the identity signal must be indistinguishable from one
   that would be shown for an unprotected HTTP transaction, unless a
   change of security level has occured.

   <Mez> 6.1.2

   <Mez> hey bill!

   <Mez> :-)

   <maritzaj> in 6.1

   <Mez> [60]http://www.w3.org/2006/WSC/track/issues/137

   <maritzaj> No claim is made about the effectiveness of these signals

   <tlr> hal, can you scribe?

   <tlr> hal?

   <tlr> ScribeNick: hal

   PHB: Identity signals are so weak users give password away even if told
   it is aphishing cite
   ... but still is worth doing
   ... if you are most vulnerable help deskk calls go way up increasing
   cost
   ... need to look at all costs, not just fraud

   tyler: current signals not sufficient?

   phb: need to give usable instructions
   ... other problem is when you know one signal is hard to change
   ... phishers create concern about security
   ... can't determine effect in usability tests

   tyler: phil may be right about reducing calls, if so I would still not
   recommend

   serge: +1

   mez: disagree

   <serge> we're arguing real security vs. perceived security

   rachna: trying to figure out what conforms and does not
   ... anything which is static will be copied by attackers

   phb: so far we are only talking about English language

   mez: agreement users can not deal with URLs

   tyler: cannot even deal with domain names

   serge: disagree with requiring EV certs

   <Mez> enable users to come to a better understanding of the context
   that they are operating in when making trust decisions on the Web;

   mez: do static indicators do this?

   tyler: no

   rachna: users could be trained

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

   maritzaj: putting it in primary chrome may not be good idea, but should
   make recommendation about secondary chrome

   phb: web has no clear instructions

6.2 Additional Security Context Information

   <Mez>
   [61]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary

   phb: agreeing with Tyler that users will respond if integrated with
   task
   ... like petname tool
   ... preferable would be like cardspace
   ... strong signal to user
   ... a part of task, e.g. banking
   ... if not present user knows they have to pay more attention

   rachna: approaches are opposite

   <Mez> it's time to stop

   <Mez> for the day

   rachna: identity signal vs. cardspace approach

   serge: when users see sites marked as untrusted that they know are
   trustworty, will undermine signal
   ... initially most sites will not be trusted

Summary of Action Items

   [NEW] ACTION: thomas to change editor's draft as outlined above
   [recorded in
   [62]http://www.w3.org/2008/02/06-wsc-minutes.html#action01]
   [NEW] ACTION: thomas to propose lang about currently interacted primary
   chrome always visible on screen [recorded in
   [63]http://www.w3.org/2008/02/06-wsc-minutes.html#action02]
   [NEW] ACTION: thomas to replace 9.3 by text above [recorded in
   [64]http://www.w3.org/2008/02/06-wsc-minutes.html#action03]
   [NEW] ACTION: thomas to update 9.2 with statement above [recorded in
   [65]http://www.w3.org/2008/02/06-wsc-minutes.html#action04]

   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [66]scribe.perl version 1.133
    ([67]CVS log)
    $Date: 2008/02/27 14:16:30 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/2008/02/05-wsc-irc
   3. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0019.html
   4. http://www.w3.org/2008/02/05-wsc-minutes.html#agenda
   5. http://www.w3.org/2008/02/05-wsc-minutes.html#a
   6. http://www.w3.org/2008/02/05-wsc-minutes.html#b
   7. http://www.w3.org/2008/02/05-wsc-minutes.html#c
   8. http://www.w3.org/2008/02/05-wsc-minutes.html#d
   9. http://www.w3.org/2008/02/05-wsc-minutes.html#e
  10. http://www.w3.org/2008/02/05-wsc-minutes.html#f
  11. http://www.w3.org/2008/02/05-wsc-minutes.html#g
  12. http://www.w3.org/2008/02/05-wsc-minutes.html#h
  13. http://www.w3.org/2008/02/05-wsc-minutes.html#i
  14. http://www.w3.org/2008/02/05-wsc-minutes.html#ActionSummary
  15. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
  16. http://www.w3.org/2006/WSC/track/issues/new
  17. http://www.w3.org/2006/WSC/wiki/WriteGoodIssue
  18. http://www.w3.org/2005/Security/wsc-charter
  19. http://www.w3.org/2006/WSC/wiki/SuccessBaseline
  20. http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-crazy-ideas/
  21. http://www.w3.org/TR/wsc-usecases/
  22. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  23. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-interactively
  24. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-certerrors
  25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  26. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  27. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-indicator-images
  28. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-login-pages
  29. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
  30. http://www.w3.org/Guide/
  31. http://www.w3.org/2005/10/Process-20051014/
  32. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  33. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
  34. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  35. http://www.w3.org/2006/WSC/track/issues/95
  36. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0233.html
  37. http://www.w3.org/2006/WSC/track/issues/131
  38. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0246.html
  39. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#whack-a-mole
  40. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirements-robustness
  41. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#definitions
  42. http://www.flickr.com/search/?q=padlock&w=all
  43. http://www.flickr.com/photos/roessler/107144618/
  44. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
  45. http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice
  46. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath
  47. http://www.w3.org/2008/02/06-wsc-minutes.html#action01
  48. http://www.w3.org/2008/02/06-wsc-minutes.html#action02
  49. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
  50. http://www.w3.org/2006/WSC/track/issues/162
  51. http://www.w3.org/2008/02/06-wsc-minutes.html#action03
  52. http://boblord.livejournal.com/1538.html
  53. http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-crazy-ideas/
  54. http://www.w3.org/2008/02/06-wsc-minutes.html#action04
  55. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
  56. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
  57. http://www.w3.org/2006/WSC/track/issues/114
  58. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#weak-tls
  59. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
  60. http://www.w3.org/2006/WSC/track/issues/137
  61. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
  62. http://www.w3.org/2008/02/06-wsc-minutes.html#action01
  63. http://www.w3.org/2008/02/06-wsc-minutes.html#action02
  64. http://www.w3.org/2008/02/06-wsc-minutes.html#action03
  65. http://www.w3.org/2008/02/06-wsc-minutes.html#action04
  66. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  67. http://dev.w3.org/cvsweb/2002/scribe/

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

Received on Wednesday, 27 February 2008 14:18:12 UTC