See also: IRC log
<trackbot> Date: 17 September 2008
<scribe> ScribeNick: steele
<scribe> Meeting: WSCWG
<Mez> http://www.w3.org/2008/09/03-wsc-minutes.html
<Mez> http://www.w3.org/2006/WSC/track/actions/pendingreview
RESOLUTION: meeting minutes are approved
mez: any issues with pending actions?
<Mez> 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> 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
tyler: can we discuss the recent favicon emails?
mez: anything else?
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0036.html
<Mez> 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> 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> 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> 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, 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 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> 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> 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> http://www.w3.org/2006/02/lc-comments-tracker/39814/WD-wsc-ui-20080724/2088
<tlr> 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?