Last meeting's minutes

Draft minutes

mez: minutes approved
... looking at newly closed action items

tlr: What is about the one about additional references from rachna, ACTION-108?

rachna: they're in the Wiki

<ses> Stuart would find it helpful if the public action items pages linked to the login page for the version that you can edit.

<Chuck> Must be too many UIs competing for our attention.

<tlr> ACTION: thomas to put documentation about action item editing interface on group page [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action02]

<trackbot> Created ACTION-159 - Put documentation about action item editing interface on group page [on Thomas Roessler - due 2007-03-27].

mez: before we transition to content part of our discussion with stuart, let's talk about editing of the note usecases
... it would be useful if we had some redundancy for usecases editors
... is someone willing to be second editor?

mez: ok, I'll put it out in email

Threat Trees

<Mez_> http://www.w3.org/2006/WSC/wiki/ThreatTrees

<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0075.html

<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0092.html

mez: ok, now stuart will lead the discussion on threat trees

<ses> http://www.w3.org/2006/WSC/wiki/ThreatTrees

ses: i haven't seen any comments on this, I've seen one change in email, does anyone need time to look this over?
... can i ask if anyone thinks there's something missing, or if there's anything that we need to go deeper with

mez: it would be useful to me, if you would give a level set of what you think the threat tree gives us
... a comprehensive set of threats we'll address?

ses: a set of threats so we can better discuss what's in scope and out of scope

tlr: i also think it would be important to use this to derive questions about what context information is useful in what use case
... i think that's the second aspect other than scope

johnathan: If we come up with a great set of UI indicators but we miss entire branches of the tree, we can't count ourselves as successful.

mez: i agree if we cover all the branches in our charter

<Chuck> What about proxies and MitM attacks? These represent threats that may not be obvious from this threat tree.

ses: ideally we would have done this before the charter, so we would have known what we were trying to address

<Tyler> I think we need a way to document in the threat tree itself which branches are out of scope

<Mez_> I agree Tyler; that's a good point

ses: we need to make sure what we're addressing will make dents in certain types of problems

<Mez_> ack hal

hal: there appears to me that there is duplication between III and IB
... one B and three
... is the difference interfering with communication instead of intercepting?

tlr: i read IB as an active attack

ses: that's what was intended

hal: is that really site impersonation?
... I has the potential goals of the attacker, i think that might be useful elsewhere

<Chuck> What about threats that represent compromises to privacy, but not necessarily direct intervention in a Web dialog? For example, theft of cookies, traffic analysis, or tracking of user's surfing.

<jvkrey> Shouldn't each "goal" have it's own attack (threat) tree?

<Tyler> Does the threat tree really mean hostname or URL where it uses "address"?

<Mez_> Chuck, can you edit the wiki page and put those in?

ses: there's a limit to how you can describe info in wiki, and bullets were the only thing i could find the show this, we neeede metainformation for branches in the tree

so bullets are meta-information for the branches?

ses: yeah

hal: i'd like to see more of them, not less. I assume the goals under I cover both the A and B case
... it's important to keep in mind what the attacker is actually trying to get at

<Chuck> I try to be careful about editing other people's work until I understand the scope and context fully.

<johnath> agree with hal's last point

hal: you'll see it at the bottom of the page if you refresh

tyler: still going through and looking at in/out of scope, we don't have anything in the out of scope section on cross-site scripting, but it's not clear to me it should be in-scope
... what do people think?

mez: i thought we agreed sandboxing didn't include security context info

hal: i suggested if you had different frames for different sites, that might be a case when you

<ses> Stuart is at a loss for how representing security context information can help with cross-site scripting. Not that he thinks it's a problem not worthy of attention.

'd want to represent things differently

tyler: i don't think you can do a cross-site scripting attack just in frames
... i think you need a code based injection into the page being served on the site

tlr: plus 1 to tyler, xss means there is a change in control and out of scope, i'd rather stick with the other stuff here

tyler: i think we should had another item to section 5 in the note

hal: so for the tree, it makes sense not to delete out of scope branches, but to not expand them and mark them in some way

<tlr> ACTION: tyler to put out-of-scope text on cross-site-scripting into Note [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action03]

<trackbot> Created ACTION-160 - Put out-of-scope text on cross-site-scripting into Note [on Tyler Close - due 2007-03-27].

<ses> Agreed with statement regarding keeping branches but not expanding them.

johnath: i might be revisiting something, xss is largely traceable to a website not being careful, but i'm weary of this being marked out of scope

<ses> <---changing his mind.

johnath: seems like the user agent knows some stuff it could be communicating to the user

<ses> <---now wondering if we can know whether any of XSS is out of scope until we expand the tree.

<Chuck> Perhaps the relevant question regarding XSS is: "Could the user's agent operate in a mode that would prevent the XSS attack?"

johnath: i'm doing this because i want to steal information, exploit a cookie, take information and transfer it to myself, the user agent has to go and make the connection to the rogue site, pages are always cross linking, if this dicussion already happened, i'm surprised, but it should be relevant to how the user makes the decision should be in scope?

mez: is there a concrete example of the context info we might consider to be inscope?

tlr: we need to distinguish, one if a website linking to a strange place that may not be what the user things it will be, this is in the use cases, where is this form being submitted to? Does this image come from the russian mafia or the real guy, what should the user be told about the origin of the content?
... xss is where the attacker gets questionable content into the legit site
... code injections are out of scope, but dealing with information being sent by form should be in scope

tyler: comments similar to tlr
... i'm worried that it's not easy for the browser to tell that the content is injected and not what the provider meant to provide. I think looking at the url is easy to talk about, but if you were writing code to do this, would it still be as easy to implement?

johnath: it doesn't have to be just submitting a form to where the user is expecting, if i can inject a script i can do things without the user taking an action
... it seems like the kind of content info that is in scope, would be having something to alert us to when information is sent to someone other than the original site

<johnath> tlr - I think you're right

bill-d: is this content coming from a poorly regarded source, and we could report that to the user

<ses> <-- still doesn't know what a user agent or reputation service is -- see http://www.w3.org/2006/WSC/wiki/Glossary

<Mez_> I believe "web user agent" is in fact in our charter.

<Mez_> that doesn't mean it's defined there; that does imply it's thought to be understood by the sort of people who read w3c charters

chuck: we're having a problem with thinking the browser is the universal user agent, but we should keep in mind browsers that have a mode with tigther settings, we should consider a browser being in a mode that might be legit in other contexts, but in the current context it's not considered safe or appropriate, this might block XSS or other potential problems

<Zakim> Thomas, you wanted to note that we're solving the halting problem

chuck: it's all relevant to the usability context we're addressing in our working group

<ses> ACTION: zurko to copy definition of web user agent to glossary [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action04]

<trackbot> Created ACTION-165 - Copy definition of web user agent to glossary [on Mary Ellen Zurko - due 2007-03-27]

tlr: for the moment we are talking more generally about a browser agent

<Chuck> I am working on AI 150. It's a tricky problem to express in a useful way.

tlr: i think in terms of scoping, we are having agreement on the basic points, so i think we should move back to the threat trees

tlr; it might be useful to not try to classify user agents, other groups have tried and failed

<tlr> ACTION: thomas to send note to chuck on prior art re ACTION-150 [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action05]

<trackbot> Created ACTION-161 - Send note to chuck on prior art re ACTION-150 [on Thomas Roessler - due 2007-03-27].

<Chuck> And worth more that other pennies I've gotten :-)

ses: the people who have come up with objections, i'm still looking for proposed changes
... if there aren't any, we can talk about how we plan to use this
... i'm not sure if i'm the right person to discuss how this will integrate with the rest of the document
... anyone else that wants to propose where we'll go to it

<Mez_> hal standing on the shoulders of giants

hal: at a minimum if we have a list of things that we should propose browsers ought to do, then we can say we have branches of the tree covered and we can check for holes
... or we can use it to look at and say, If I knew X then I could prevent this branch

ses: anyone object to having recommendations that address branches of the tree

beltzner: should be based on the user goals, not on what the attacks are

beltzner: where are we taking into account the user task, it should be the browser who tells that people are at the right place

<ses> (do we want to take a moment to look at the "use case dimensions" wiki page?

<Mez_> ses, put in url; I don't know what you're saying

<ses> http://www.w3.org/2006/WSC/wiki/Use_Case_Dimensions

ses: are we getting to a halting problem, asking the browser to make the call of user intent and where they think they should be

johnath: i agree our recommendations should be driven by the user expectations, the threat tree isn't that, but complements it, the tree makes sense as a sanity check to say what the potential attacks are, because we're not thinking of ways to attack the system. So the threat tree should be the attacker's model, not the user's model. Using the tree as a check.

tyler: having the browser make a decision about where the user thinks they are doesn't need to be as scary a problem as people are making it, for example if you're typing in a password, then the browser just needs to know the user is about to send something sensitive to a remote site

hal: i agree it's annoying when a browser tells you you're about to send sensitive info when all you did was click

chuck: i also think we need to come back to the mutual aspect of this, it's the user and the webstie
... what are the constraints that the site should have, how can the site stipulate that the user's agent should be in a restricted moed

<Mez_> I think Chuck's statement implies new protocols, which are out of charter

chuck: a mechanism like this that would tell the user that they'e in this mode would help, we need to look at it from both the user and browser point of view

<beltzner> mez_, not neccessarily ... a simple tag is all that's needed, no need to go through any protocol or standards group, just start telling people that it'll work and start supporting it and then let the standard emerge

<Mez_> where is the sensitive field markup going on?

<ses> <---agrees with Chuck---but doesn't think it goes in HTML

<Chuck> But how does that new mode get communicated to the user???

tlr: getting back to tyler's question, i think there is a point around getting mark-up for sensitive form fields or something, it's in scope for what's going on elsewhere and we're free to suggest recommendations in that direction
... i'm encouraging people to write up these proposals as recommendations for what the browser should implement

tyler: tlr has the right approach, let's clarify, i don't think this info is something we can get from html, we can't trust the site to say this is or isn't a sensitive field

<ses> (I'm pretty sure users will can be convinced not to activate the bit.)

<Chuck> I agree with Tyler's comment. This is a problem that can only be addressed by working both ends simultaneously.

<Mez_> give tyler an action. The worst he can do is ignore it :-)

bill-d: we also have that the server could raise the bar and the user could say these are the sites that i want to be secure. there could be a type of exchange to raise the level of security within a session

mez: do we have a number of proposals that merit follow-up?

<Chuck> Rather than comparing this to the "halting problem" (which it's not), this is closer to one of the various "voting problems."

<tlr> ACTION: tyler to draft "sensitive piece of information" proposal [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action06]

<trackbot> Created ACTION-162 - Draft \"sensitive piece of information\" proposal [on Tyler Close - due 2007-03-27].

rachna: i've been testing does the user think they're sending sensitive info, and does the user know where they are

<tlr> ACTION: rdhamija2 to draft "where am I" outline due 2007-03-28 [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action08]

<trackbot> Created ACTION-163 - to draft \"where am I\" outline due 2007-03-28 [on Rachna Dhamija - due 2007-03-27].

rachna: we're doing some early prototyping

tyler: could you tell us more about the second one

rachna: we dont know that yet

mez: what are the next steps with the threat trees

ses: i'd like a volunteer who understands xss well to expand the branch
... if we expand it we might find something that's in scope

johnath: i can take an action to add some detail for discussion

ses: my guess is that expanding this branch will show there are a bunch of attacks that fall into the xss category, you might end up with things that look like major branches that are under II

<tlr> ACTION: johnathan to elaborate cross-site-scripting branch of threat tree with view toward user understandable context information - due next 2007-03-28 [recorded in http://www.w3.org/2007/03/20-wsc-minutes.html#action09]

<trackbot> Created ACTION-164 - elaborate cross-site-scripting branch of threat tree with view toward user understandable context information [on Johnathan Nightingale - due 2007-03-28].

ses: i'd also like to make a proposal that we have a reward for someone who finds holes in the threat tree

mez: tell me how to judge that one

tyler: for builiding the xss branch, if we come up with html additions, can we pass them off to the other working group

tlr: sure

hal: is there another group for forms and security

tlr: that group did not happen, but the charter got dropped into the forms group short description from that charter, which is now with the html group, but they need technical input - possibly from our members

mez: stuart, any quick wrap-ups
... all members are presumed to have read the use-case notes
... everyone should have comments by april 4th, even if it's just i read it and i don't have comments

tlr: if the threat tree is stable should be drop it into a draft of the note?
... if we don't touch this for a few weeks we should add it

mez: reminder for the new meeting time and date
... wednesday march 28th at 11 am est

tlr: also we're joining the US in with daylight savings

<beltzner> mez_, I have a process question for you, if you can hang on for a few minutes after the call

<Mez_> sure