- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 24 Sep 2008 17:06:48 +0200
- To: public-wsc-wg@w3.org
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