Web Security Context Working Group Teleconference
17 Sep 2008

See also: IRC log


+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
Martiza_J, Johnathan_N




<trackbot> Date: 17 September 2008

<scribe> ScribeNick: steele

<scribe> Meeting: WSCWG

picking a scribe

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

Approve Minutes from prev meetin

<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

Agenda bashing

tyler: can we discuss the recent favicon emails?

mez: anything else?

FAVICON email thread

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

Summary of Action Items

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

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