Meeting record: WSC WG weekly 2008-09-17

Minutes from our meeting on 2008-09-17 were approved and are
available online here:

   http://www.w3.org/2008/09/17-wsc-minutes.html

A text version is included below the .signature.

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




   [1]W3C

               Web Security Context Working Group Teleconference
                                  17 Sep 2008

   See also: [2]IRC log

Attendees

   Present
          +1.781.306.aaaa, MaryEllen_Zurko, +1.925.984.aabb, phb,
          joesteele, yngve, +1.202.386.aacc, Thomas, ifette,
          +47.23.69.aadd, jvkrey, tyler

   Regrets
          Martiza_J, Johnathan_N

   Chair
          Mez

   Scribe
          steele

Contents

     * [3]Topics
         1. [4]picking a scribe
         2. [5]Approve Minutes from prev meetin
         3. [6]Agenda bashing
         4. [7]FAVICON email thread
     * [8]Summary of Action Items
     __________________________________________________________________



   <trackbot> Date: 17 September 2008

   <scribe> ScribeNick: steele

   <scribe> Meeting: WSCWG

picking a scribe

   <Mez> [9]http://www.w3.org/2008/09/03-wsc-minutes.html

Approve Minutes from prev meetin

   <Mez> [10]http://www.w3.org/2006/WSC/track/actions/pendingreview

   RESOLUTION: meeting minutes are approved

   mez: any issues with pending actions?

   <Mez> [11]http://www.w3.org/2006/WSC/track/actions/open

   mez: no -- then closing
   ... reviewing open action action items
   ... some action items are red -- can anyone deal with them

   tyler: no way to put my text in now

   mez: re ACTION 336, 368?

   <tlr> ACTION-492?

   <trackbot> ACTION-492 -- Phillip Hallam-Baker to contact ebay about
   paypal web authoring best practices -- due 2008-07-23 -- OPEN

   <trackbot> [12]http://www.w3.org/2006/WSC/track/actions/492

   mez: phil -- ACTION 492? deal with that?

   phb: yes -- dealing with it

   mez: ygnve?

   ygnve: would be finished already, but here instead :-)

   mez: please update the due date if possible

   yngve: expect to be done today

   mez: ACTION 513? what's the resolution?

   tyler: leaving open for now

Agenda bashing

   tyler: can we discuss the recent favicon emails?

   mez: anything else?

FAVICON email thread

   <Mez>
   [13]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0036.html

   <Mez>
   [14]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0031.html

   tyler: working on petname tools in FF3 and looking at compliance with
   our recommendations, looks like it violates Section 7.2. Is the text
   ambiguous? Do people agree? Does this mean feature is at risk?

   mez: Any screenshots available?

   tyler: could make that available for the wiki

   <Mez> [15]http://www.w3.org/TR/wsc-ui/#site-identifying

   tyler: where to put the image?

   mez: under conformance testing perhaps?

   tyler: sending to public mailing list instead for now

   <Mez>
   [16]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0039.html

   tyler: left of the URL bar is the favicon. URL and favicon are
   controlled by the site. Popup from pressing favicon is effective TLD of
   the site

   tlr: background of the favicon encodes whether trust is active or not

   tyler: spec says this kind of information cannot be controlled by the
   site

   tlr: three choices
   ... 1) deemed to be inconsistent with our spec -- this does not mean
   this is a feature at risk. Those are for things which we reserve to the
   right to remove from the spec
   ... i.e. we are not entirely sure and would be happy to drop it

   tyler: paraphrasing -- either a feature at risk or a show stopper?

   tlr: precisely

   tyler: can we go around the room and see how people would vote?

   mez: discussion first

   ygnve: Opera has identity signal on the right side to make it visually
   separate
   ... seems at least borderline on security

   prev referred to Mozilla

   tlr: probably beyond borderline, would be interesting to understand the
   real impact better
   ... before we discuss the merits would like to have others on the call

   ifette: going by what johnath has said in the past -- secure chrom is
   what you get after you click on the chrome. Trust information cannot be
   mimiced in this area. Also favicon cannot mimic the background. This
   probably meets the spec

   dans: that's not the main question I have ...
   ... FF gives you the name in the chrome thats content, but can other
   content be moved into the chrome. This is what we are trying to prevent

   mez: I think we are dealing with that in other sections.
   ... if a gap, we should address. I agree with the intention

   tyler: follow up on ians comment. only security info presented is the
   presence or not of SSL?
   ... favicon should not be interpreted as part of the secure chrome

   <tlr> that's spec lawyering to a point where (I think) it gets
   problematic.

   <tlr> tyler, it's not the effective TLD, but the effective SLD

   dans: yes

   tyler: but the effective TLS is also content controlled by the site
   owner

   dans: but not arbitrary -- it is validated. chosen by attacker, but
   valid information. The browser knows the site you are connected to.

   <tlr> rathole!

   tyler: FF implementation is only telling you your are connected to that
   site, all the other bits of information are misleading?

   tlr: is there anything in the validated certificate which can be shown
   to the user?

   tyler: primary -v- secondary chrome distinction. is popup secondary?

   dans, mez: secondary

   <tyler>
   [17]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0040.html

   <tyler> figure with the pop

   ygnve: is access to the identity signal going through secure chrome?

   tlr: seems that validated -v- non-validate stuff is varied using
   non-spoofable mechanism that is ok. Mechanism may vary but that is ok

   tyler: is opinion that the blue background behind the favicon the
   primary secure chrome for FF3? or is there another area?

   <Zakim> Thomas, you wanted to answer to tyler

   tlr: domain name there is also secure chrome
   ... less reservation about the domain name
   ... domain name is domain from the URL?

   <Mez> the response of FF to the first paragraph of 7.2 is

   <Mez> Firefox 3 does not use chrome to signal trust information in a
   way that would be mimicked by site controlled content.

   dans: what other issues arise?

   <Mez> thereby equating direct mimicking with confusion

   <Mez> which certainly seems to be a reasonable low bar

   <Mez> but as tyler asks, is the low bar our bar

   tlr: could use a confusing domain name combined with other attacks

   <Zakim> yngve, you wanted to comment on wildcards

   yngve: cannot use a star plus dot in name in Opera -- get a warning

   tyler: mountain america attack -- where attacker registered
   mountainamerica domain and is displayed in multiple places along with
   branding

   mez: mimicing is equated with user confusion in some conversations, but
   that is a pretty low bar, but we have not defined the bar we will use.
   A metaquestion -- would we take out 7.2? it looks to me that we have a
   low bar which would leave that section in.

   tlr: also hearing -- are we happy with that low bar?

   tyler: is the question clear enough that we can answer?

   mez: not apparently

   tyler: also would we proceed with UI if 7.2 is dropped?

   <Mez> rephrase - would we proceed with UI if 7.2 is downgraded to
   "mimic" instead of "confuse"

   ygnve: IIRC -- Opera moved identity signal to right side because it was
   considered confusing

   mez: clearly Opera has an idea of what confusing means. Let me playback
   -- things that are close to content driven chrome are confusing. A
   security indicator that is close to content driven chrome that could be
   close to a [valid] security indicator is confusing.

   tyler: q: for yngve -- what info does Opera communicate in primary
   security chrome?

   yngve: padlock, domain name with background color

   ygnve: also show whether it was a wildcard that matched domain

   tyler: so is the hostname site content?

   yngve: it is part of the information we have available -- it is part of
   the certificate

   tyler: but it came from the site?

   dans: true for EV sites also

   phb: spent a lot of time specifying the concept of the identity signal
   without saying what it can be
   ... quality of implementation may vary and we can't tell them otherwise

   <Mez> tyler, I think I don't have your definition of confusing crisply
   in my head. can you state it?

   <ifette> FWIW,
   [18]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0041.html

   tlr: I lean towards saying this is not a feature at risk. Maybe it
   needs to be tightened a bit more?

   mez: I agree. Two potential ways to tighten it ...

   1. pure mimicing

   2. what Opera is following (described above)

   mez: tyler do you have an idea of what tighter text would be?

   tyler: not yet

   mez: but looks like there is an issue here?

   tyler: yes -- the wording depends on whether people consider this site
   content or not

   tlr: would like to see wording if it was considered site content

   tlr: would not consider the host name site content

   tlr: but would like to see some text written that way

   tyler: the bits that came from the site can't be rendered in the
   security chrome (?)

   steele: tyler -- please rephrase as needed -- I did not catch all of
   that

   mez: I could draft cripser text based on the responses from Opera and
   Mozilla so far

   ifette: we would need to redraft to include the applicable DNS name
   from the cert

   tlr: we would need to reopen to include that

   tlr: I am hearing we might want to reopen 7.2 -- but would like to hear
   johnath opinion

   <yngve> 6.1.2. If the identity signal does not include any other human
   readable information about the identity of the certificate subject
   (derived, e.g., from an augmented assurance certificate or a petname),
   then it MUST include an applicable DNS name retrieved from the
   subject's Common Name attribute or from a subjectAltName extension.

   <ifette> I have to drop off, have another meeting, but I like 7.2 and i
   certainly don't want to revisit 6.1.2

   mez: I can take that action of tightening the text. More discussion?

   <tlr> ACTION: mez to propose tightened text in 7.2 [recorded in
   [19]http://www.w3.org/2008/09/17-wsc-minutes.html#action01]

   <trackbot> Created ACTION-515 - Propose tightened text in 7.2 [on Mary
   Ellen Zurko - due 2008-09-24].

   <Mez>
   [20]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0019.html

   mez: continue to last call comments?

   tyler: what is the status of the current document?

   tlr: we do make limited edits but need to explain them all and track
   closely

   tlr: ideally we would not see any changes from the working group

   tlr: we can clarify and make minor changes, but major changes could
   trigger another last call

   tlr: possibly also comments/suggestions from outside as well

   tlr: is there a particular change in mind?

   tyler: yes -- in the petname section had to change the matching
   algorithm

   tyler: needed something that could be implemented in IE and FF in the
   spec

   <tlr> tyler: have implementation feed-back about petnames

   <tlr> tlr: please send to mailing list

   tlr: another implementer for this spec would be good

   tyler: another comment -- commented from an IETF reviewer thought is
   was strange that we were reviewing something not implemented

   <Mez> Section 5.1.6: I have not used petnames, nor do I know much about
   their

   <Mez> usage in the context of this document, so treat the rest of this
   comment

   <Mez> as feedback tinged with curiosity from someone uninitiated with
   the

   <Mez> workings of W3C and unaware of how pervasive the petname concept
   is

   <Mez> in that domain (certainly, I do not think I have ran across a
   current

   <Mez> browser that uses petnames in its chrome.) Please treat this as a

   <Mez> pure comment and not anything that needs resolution.

   <Mez> It seems to me that the petname is a concept layered on top of
   the

   <Mez> information present in X.509 certificates. As such, it is a level
   of

   <Mez> abstraction above the X.509 certificate. Especially, the petname

   <Mez> implementor would have to account for wildcards, delegation, etc.

   <Mez> If care is not taken to write a good implementation, then
   security could

   <Mez> be -- I think -- compromised by someone modifying the contents of
   the

   <Mez> petname database, or by other means.

   <Mez> If any action item results from this comment at all, it would

   <Mez> be along one or more references on more information into the

   <Mez> petname concept, especially any papers that outline the threat

   <Mez> model of using such a concept. I Googled and ran across

   <Mez>
   [21]http://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname,

   <Mez> but that does not contain a threat analysis of this concept. It

   <Mez> does, however, explain very well the concept of a petname.

   <tlr>
   [22]http://www.w3.org/2006/02/lc-comments-tracker/39814/WD-wsc-ui-20080
   724/2088

   <tlr> [23]http://www.w3.org/mid/48BE9CAC.4080602%40alcatel-lucent.com

   tyler: is it enough that the code exists -- or does it need to be
   widely deployed?

   tlr: I would read this as "need to be more security analysis and has
   this been reviewed sufficiently?"

   tyler: what effect does this have on the final version?

   tlr: up to the working group I think

   tlr: one question is whether we need to review the petname mechanism
   more -- a change to the algorithm may trigger more discussion

   tyler: has been discussed on the mailing list -- would this help?

   mez: any more?

Summary of Action Items

   [NEW] ACTION: mez to propose tightened text in 7.2 [recorded in
   [24]http://www.w3.org/2008/09/17-wsc-minutes.html#action01]

   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [25]scribe.perl version 1.133
    ([26]CVS log)
    $Date: 2008/09/24 15:06:15 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/2008/09/17-wsc-irc
   3. http://www.w3.org/2008/09/17-wsc-minutes.html#agenda
   4. http://www.w3.org/2008/09/17-wsc-minutes.html#item01
   5. http://www.w3.org/2008/09/17-wsc-minutes.html#item02
   6. http://www.w3.org/2008/09/17-wsc-minutes.html#item03
   7. http://www.w3.org/2008/09/17-wsc-minutes.html#item04
   8. http://www.w3.org/2008/09/17-wsc-minutes.html#ActionSummary
   9. http://www.w3.org/2008/09/03-wsc-minutes.html
  10. http://www.w3.org/2006/WSC/track/actions/pendingreview
  11. http://www.w3.org/2006/WSC/track/actions/open
  12. http://www.w3.org/2006/WSC/track/actions/492
  13. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0036.html
  14. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0031.html
  15. http://www.w3.org/TR/wsc-ui/#site-identifying
  16. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0039.html
  17. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0040.html
  18. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0041.html
  19. http://www.w3.org/2008/09/17-wsc-minutes.html#action01
  20. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0019.html
  21. http://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname
  22. http://www.w3.org/2006/02/lc-comments-tracker/39814/WD-wsc-ui-20080724/2088
  23. http://www.w3.org/mid/48BE9CAC.4080602%40alcatel-lucent.com
  24. http://www.w3.org/2008/09/17-wsc-minutes.html#action01
  25. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  26. http://dev.w3.org/cvsweb/2002/scribe/

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

Received on Wednesday, 24 September 2008 15:07:25 UTC