- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 14 Mar 2007 15:02:48 +0100
- To: public-wsc-wg@w3.org
The minutes from our meeting on 6 March have been approved. They
are online here:
http://www.w3.org/2007/03/06-wsc-minutes
Regards,
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
WSC WG weekly
6 Mar 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Mary Ellen Zurko
Thomas Roessler
Jan Vidar Krey
Johnathan Nightingale
Maritza Johnson
Phillip Hallam-Baker
Hal Lockhart
Chuck Wade
Paul Hill
Tony Nadalin
Mikc McCormick
Bill Doyle
Rob Franco
Rachna Dhamija
George Staikos
Regrets
Chair
Mary Ellen Zurko
Scribe
Mike Beltzner
Contents
* [4]Topics
1. [5]daylight saving time
2. [6]approval of past meeting's minutes
3. [7]Robustness of security indicators
* [8]Summary of Action Items
_________________________________________________________________
daylight saving time
<tlr> We're on US time. Europeans beware.
<tlr> ACTION: zurko to send reminder concerning out-of-order US DST change
[recorded in [9]http://www.w3.org/2007/03/06-wsc-minutes.html#action01]
<trackbot> Created ACTION-147 - Send reminder concerning out-of-order US DST
change [on Mary Ellen Zurko - due 2007-03-13].
approval of past meeting's minutes
Mez_: reviewing minutes from last meeting
... minutes approved!
<tlr> [10]http://www.w3.org/2007/02/20-wsc-minutes
Mez_: agenda item 1: closed a bunch of actions due to lack of activity
... also some team members are finding time to close off more items, too
... any issues with these items being closed?
<Mez_>
[11]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0000.html
Mez_: on to the actual "content" part of the agenda
... now discussing "Robustness of security indicators"
<Mez_> [12]http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice
Mez_: points out that discussion has been rolling along on email list
... are staikos or franco present?
... my email went over a couple of robustness techniques discussed in
literature, giving examples of each
... going to move this to the wiki so we can continue to flesh out the part
of the recommendation
... categories are 1) making them hard to guess, 2) designing a trusted
path, 3) one-off techniques targeted at specific kinds of attacks
... any better way to structure?
... 1) making them hard to guess ...
... ... use shared secrets or a "naming" step (petnames) or dynamic security
skins ("tartans")
beltzner: I like the name "tartans" if we're trying to build metaphors
johnath_moz: seconded!
<Chuck> Problem is that it relates to only a portion of the Western world.
<Nadalin> Remember the Tartans
johnath_moz: it's worthy of note that using security skins tends to be
ignored by users in a picture in picture attack
... but I bet you've discussed that before
Mez_: there's some great shared bookmarks on the wiki, if you'd like to add
to it
<johnath_moz> [13]http://www.usablesecurity.org/papers/jackson.pdf
johnath_moz: I was referring to Jackson, MSR, et al.
Mez_: make sure it's in shared bookmarks
... any other examples of shared secret?
beltzner: does two-factor auth fit in here?
<Chuck> Aside: We should be careful about the term "shared secret." Sharing
secrets is always a difficult, if not intractable, problem. In general,
schemes that are based on "private" or non-shared secrets tend to be more
robust.
Mez_: how does that make a security indicator robust against spoofing?
johnath_moz: right, that's my read on it, too; it doesn't reduce spoofing,
it just makes the attack useless
Mez_: right, second paragraph of 2) in my email refers to this
<Chuck> We should also be careful about saying that a technique "makes an
attack useless." The problem is that another attack might be very
successful, even in the presence of the security measure.
beltzner: that makes sense as long as this section is scoped to "making web
chrome signals secure" as opposed to just "better ways of securing
transactions on the web"
<Chuck> Many multi-factor auth techniques are vulnerable to a variety of
well-known attacks.
johnath_moz: I think we should avoid designing new protocols to secure
transactions
Mez_: so two-factor authentication layers on top of existing protocols
johnath_moz: right, it's still using standard POST forms
<Chuck> We already have TLS (SSL), which can be a foundation for
multi-factor auth, and also mutual auth. Perhaps the problem we should focus
on is how to get Web applications to make effective use to the technology
already widely deployed
<Mez_> [14]http://www.w3.org/2006/WSC/drafts/note/#available
Mez_: should these items be in s7 ("Available security information) of our
note?
johnath_moz: yes, they should
<Chuck> Whether or not these should be in Section 7 somewhat gets to the
question of the purpose of the "Note." It's probably more important to start
the dialog about where to address this in the forward work of this group.
johnath_moz: argues for a subsection added to s7 to list "provided by the
site I'm trying to interact with"
bill-d: hey! you're talking about multi-factor auth!
<Chuck> Remember, FFIEC was very careful to not "require" two-factor auth.
beltzner: I brought it up, but am now regretting it
bill-d: it's not a real authentication mechanism ... not a pure
identification mechanism
<Chuck> All FFIEC required was that Banks "take it up a notch" (quoting
Michael Jackson, the FDIC Director, not the singer)
johnath_moz: right, and now we're considering adding a subsection to S7 that
would list "provided by the site"
<johnath_moz> SRP = Secure Remote Passwords
<Chuck> Isn't the issue that's relevant to this group how Web applications
facilitate user interfaces with improved security techniques (measures), not
the specifics of the technologies?
beltzner: I also brought up SRP a while back, as a way of securing
transmission between forms
<tlr> tlr: if you use SRP, you want to make sure that the password goes into
the client-side SRP code and isn't just transmitted to whatever service
we're talking to. Therefore, people must be able to tell these apart.
Mez_: I'm not sure that our note has the right context here ... there's an
action item here about starting the discussion, candidates are myself or
beltzner?
beltzner: how about johnath?
tlr, with SRP, that doesn't matter, actually ... that's the whole design of
SRP
<tlr> ACTION: johnathan to start discussion on technology-layer security
context [recorded in
[15]http://www.w3.org/2007/03/06-wsc-minutes.html#action02]
<trackbot> Created ACTION-148 - Start discussion on technology-layer
security context [on Johnathan Nightingale - due 2007-03-13].
johnath_moz: "technology layer security context" should be enough to remind
me of what we're talking about
Mez_: so, back to category 1)
([16]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0000.html)
... "shared-secret" seems to be confusing ... is there a better term?
<johnath_moz> Mez, agree
beltzner: these are all activities that identify or customize their
relationship with the site ... dunno a good word there
johnath_moz: doesn't have to be a concious decision on the part of the user,
seems to be that it's hard to guess
<Chuck> The problem is that there are *many* security techniques that need
to be combined to achieve effective solutions. "Shared secrets" are merely a
subset of the overall suite of techniques that need to be addressed.
Mez_: yeah, I think limiting it to customization might be overly restructive
Chuck, sure, but we're talking about using this as a structure for the note;
if you think that's wrongminded, raise that point
<tlr> chuck, I think it would be good to propose recommendation material
that says so.
<tlr> beltzner, I hope you meant "rec", not "note"
tlr, I don't think I know the difference ..
Chuck: if we keep talking about shared secrets, we're going to try to
support the one technology that doesn't work very well
... passwords, for example, are shared secrets
... the problem is that _if_ we're going to insulate users from the problems
of managing shared secrets, we need to provide the right kind of usability
interfaces to work with things that are convienient and be able to interface
with a system that hides those secrets from disclosure of those secrets
beltzner: whoa, whoa, all we're doing is trying to categorizing the
techniques
<tlr> ACTION: wade to make FSTC's list of techniques available to group
[recorded in [17]http://www.w3.org/2007/03/06-wsc-minutes.html#action03]
Chuck: the FSTC did that already, and it's a pretty big list
<trackbot> Created ACTION-149 - Make FSTC\'s list of techniques available to
group [on Chuck Wade - due 2007-03-13].
tlr: we have a phase where we go through the individual proposals
... if chuck thinks that there is specific technologies that would be useful
to recommend, it would be good to write those up
Mez_: yes, please, start a thread or schedule a set of agenda items
Chuck: what struck me about this dialog is that we've identified one
authentication technique rather than recognizing the security context that
needs to be recognized to users
... there are many other techniques that need to be taken into account
... concern I had was that this is becoming a narrow focus, as opposed to
presenting a consistent set of security context information to users
Mez_: do you want to start a thread or schedule agenda items?
Chuck: maybe? lemme think about that
Mez_: OK! 'cause everyone's agreeing, so let's go
Chuck: I think this group's unique value is to suggest ways of providing
consistent signals of security context
Mez_: ok, moving on to category two, which is "designing a trusted path
around security indicators"
... idea was that there would be some sort of mode or interactive ceremony
where it's impossible for content to spoof security indicators
... safe browsing proposals, other chrome limited approaches ...
Chuck: the way the title is worded strikes me as odd ...
hal: : use "to enable" instead
Mez_: sure, fine, yup
<johnath_moz> heck, you could just say "2) Trusted Paths"
<tlr> johnathan, that's too simple
<johnath_moz> tlr, :)
beltzner: there are way of desinging indicators that can't be spoofed, for
example, by crossing over the chrome/content barrier in ways that are
non-spoofable
<johnath_moz> we're nothing if not "great deal of thought" people :)
beltzner: f.e., in firefox 2+, go to
[18]http://www.mozilla.com/firefox/its-a-trap.html
<johnath_moz> (mez, that was mike b, not me)
Mez_: beltzner posted the Mozilla techniques, are there others?
rfranco: with regard to not showing rogue HTML, in IE there are a couple of
simple principles
... f.e. I can't render HTML above the address bar or status bar (above =
y-axis)
Mez_: is that all?
beltzner: not even the mozilla list is complete atm, we should get similar
lists for IE and KDE generated and then can flesh 'em out on the wiki
tlr: notes that contributions to the rec should be made after committing to
the patent policy
Chuck: I'm not sure where else this belongs but the issue of "it isn't just
browsers" should be referenced here
Mez_: I'd like some people to pony up examples that aren't browsers
Chuck: iTunes has security indicators
Mez_: what are they?
<staikos> most apps leave out or use very broken security indicators
relative to browsers
Chuck: I'm putting forward the point that browsers aren't the only
applications that will need to communicate security indicators
<staikos> Mail.app is my favorite annoyance right now
tlr: at the candidate recommendation phase we might be looking for examples
of non-web browser user agent techniques
<staikos> also many of these apps are actually using almost all of a web
browser except for the chrome, such as mail or IM apps
Chuck: f.e. cardspace: it's a user-security context presentation that's not
part of a browser, could span multiple user agents and applications. Is it
the kind of thing we want to be recommending in this document, or is it out
of scope?
rfranco: I'm actually part of the team at MSFT and I think that there's
value in cardspace being part of this discussion
... the adobe guys are on the call for a reason, too, presumably for their
products
<staikos> kwallet spans multiple applications and works quite well IMHO.
When in the browser context, it integrates so tightly that many users think
it's actually a part of the browser
rfranco: any user agent that will host potentially untrusted content will
want to pay attention to these guidelines
<staikos> so in other words I agree with rfranco
staikos, happy to be helping you not have to listen
<staikos> this call is 100x more interesting than the other two I'm on :P
Chuck: this applies to robustness in that it's a consistent interface to
users and invokes an OS-level trusted UI which is inaccessible from
non-trusted content
Mez_: got 4 minutes left ... anyone burning with a desire to speak?
tlr: ... the burning question I would have would be what are the actions
falling out of this discussion
beltzner: the action is being considered by chuck, iirc
Mez_: and I'd like to see it go to the wiki in terms of recommendations, etc
tlr: I think the action that wasn't recorded is the one concerning
describing/suggesting classes of presenting information
... drilling down in sufficiently abstract terms what agents we're talking
about
<Mez_> I hope so, since I don't quite understand the conformance class
aspect
Chuck: I'll try to get something out to the group ... I'll take a stab at it
<tlr> ACTION: chuck to propose text do drill down on possible classes of
conforming implementations -- more concrete than note, more abstract than
products [recorded in
[19]http://www.w3.org/2007/03/06-wsc-minutes.html#action04]
rfranco: you can use me as a resource to talk about cardspace
<trackbot> Created ACTION-150 - Propose text do drill down on possible
classes of conforming implementations -- more concrete than note, more
abstract than products [on Chuck Wade - due 2007-03-13].
tlr: next week's call will be an hour earlier (relative) for folks in EU due
to the new DST practices in the US
Mez_: this thursday is the absolute last chance to discuss the rescheduling
of the call, too
[20]http://www.w3.org/2002/09/wbs/39814/wscweekly2/
Summary of Action Items
[NEW] ACTION: chuck to propose text do drill down on possible classes of
conforming implementations -- more concrete than note, more abstract than
products [recorded in
[21]http://www.w3.org/2007/03/06-wsc-minutes.html#action04]
[NEW] ACTION: johnathan to start discussion on technology-layer security
context [recorded in
[22]http://www.w3.org/2007/03/06-wsc-minutes.html#action02]
[NEW] ACTION: wade to make FSTC's list of techniques available to group
[recorded in [23]http://www.w3.org/2007/03/06-wsc-minutes.html#action03]
[NEW] ACTION: zurko to send reminder concerning out-of-order US DST change
[recorded in [24]http://www.w3.org/2007/03/06-wsc-minutes.html#action01]
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [25]scribe.perl version 1.128 ([26]CVS
log)
$Date: 2007/03/14 13:54:00 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0022.html
3. http://www.w3.org/2007/03/06-wsc-irc
4. file://localhost/home/roessler/W3C/WWW/2007/03/06-wsc-minutes.html#agenda
5. file://localhost/home/roessler/W3C/WWW/2007/03/06-wsc-minutes.html#item01
6. file://localhost/home/roessler/W3C/WWW/2007/03/06-wsc-minutes.html#item02
7. file://localhost/home/roessler/W3C/WWW/2007/03/06-wsc-minutes.html#item03
8. file://localhost/home/roessler/W3C/WWW/2007/03/06-wsc-minutes.html#ActionSummary
9. http://www.w3.org/2007/03/06-wsc-minutes.html#action01
10. http://www.w3.org/2007/02/20-wsc-minutes
11. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0000.html
12. http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractise
13. http://www.usablesecurity.org/papers/jackson.pdf
14. http://www.w3.org/2006/WSC/drafts/note/#available
15. http://www.w3.org/2007/03/06-wsc-minutes.html#action02
16. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0000.html)
17. http://www.w3.org/2007/03/06-wsc-minutes.html#action03
18. http://www.mozilla.com/firefox/its-a-trap.html
19. http://www.w3.org/2007/03/06-wsc-minutes.html#action04
20. http://www.w3.org/2002/09/wbs/39814/wscweekly2/
21. http://www.w3.org/2007/03/06-wsc-minutes.html#action04
22. http://www.w3.org/2007/03/06-wsc-minutes.html#action02
23. http://www.w3.org/2007/03/06-wsc-minutes.html#action03
24. http://www.w3.org/2007/03/06-wsc-minutes.html#action01
25. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
26. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 14 March 2007 14:02:46 UTC