See also: IRC log
<tlr> We're on US time. Europeans beware.
<tlr> ACTION: zurko to send reminder concerning out-of-order US DST change [recorded in 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].
Mez_: reviewing minutes from last meeting
... minutes approved!
<tlr> 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_> 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_> 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> 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_> 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 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) (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 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 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 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