Web Security Context WG Teleconference
18 Jul 2007


See also: IRC log


Shawn Duffy, Thomas Roessler, Tyler Close, Jan Vidar Krey, Tim Hahn, Stephen Farrell, Hal Lockhart, Audian Paxson, Yngve Pettersen, Chuck Wade, Johnathan Nightingale, Luis Barriga, Anil Saldhana
Serge Egelman, Rachna Dhamija, Maritza Johnson, Bill Doyle, MEZ



Approve minutes from last meeting

<tlr> http://www.w3.org/2007/07/11-wsc-minutes

<tlr> RESOLUTION: minutes accepted

agenda bashing

tlr: I have 3 substantive agenda items, any others?
... first, review use cases note
... also would like an update from sduffy
... then self signed certs, then browser lockdown

<tlr> no changes

wsc-usecases progress

<tlr> http://www.w3.org/2006/WSC/drafts/wsc-usecases/

tlr: tyler, can you give us a quick update

tyler: I think right now, the ball is in my court on a number of things
... tlr's note, one or two issues where consensus has been declared, but the changes haven't been made
... also, some changes tlr suggested in email didn't make it in

<tlr> process part is ISSUE-73

tyler: I was hoping to go through threat trees again, but no time

<tlr> ISSUE-6

tlr: have you had a look at mobile (issue 6)?
... I believe we have 2 proposed additional use cases, and discussion seems to have slowed

tyler: I don't think I've looked at it yet

<tlr> http://www.w3.org/2006/WSC/Group/track/issues/6

tyler: are they in the most recent emails, linked from tracker?
... I don't see a declaration of consensus

tlr: we haven't quite declared consensus
... I see from the most recent emails that there is one use case, and one change to section 10. I'm happy to let this linger, and/or close the decision today
... any opinions?

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0198.html

luis: from my side, it looks okay

tlr: my suggestion to tyler would be to have a look at clearing up "prior interaction", extract the use case, extract the changes to 10.1.1, make the changes, and put it out for reveiw

tyler: That's possible.

tlr: by what deadline?

tyler: you already built in a deadline of next week

<tlr> ACTION: tyler to extract changes from ISSUE-6, sort out "prior interaction" confusion, if any [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action01]

<trackbot> Created ACTION-269 - Extract changes from ISSUE-6, sort out \"prior interaction\" confusion, if any [on Tyler Close - due 2007-07-25].

<tlr> ISSUE-38

<tlr> http://www.w3.org/2006/WSC/Group/track/issues/38

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0120.html

tlr: this issue has a proposal from Jun 15, no traffic since, I think that counts as consensus

<tlr> RESOLUTION: ISSUE-38 closed; text from Mez to be added to draft

tlr: given silence on the phone, I'll record it as closed

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html

tlr: I sent an email with proposed disposition for 11 issues, but unfortunately we haven't heard from Bruno or Rob, the originators of these
... the proposal would be to reassign 78 to rec-track documents, and close the others without change, though with extra notes, in some cases
... I would like to briefly review a couple
... first, 82, shared use, the proposal is to reject this issue since we have had ample discussion on "shared systems" already, and closed the discussion
... next, 88, around information architecture, there hasn't been any followup from Bruno as to what that would mean for the group
... if anyone can recommend meaningful things around this issue, speak up

tyler: before we leave issue 88, the text description is short, but looks similar to language in the note - what's the difference?

tlr: I understand what the note says about "authoring applications", but not what it means to "recommend use of information architecture" in any concrete way
... issue 94 has at least 4 subpoints...

<tlr> http://www.w3.org/2006/WSC/Group/track/issues/94

tlr: first - the portability of settings across platforms and technologies - not sure it's in scope

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0100.html

tlr: of the 4 subpoints, some replicate other issues, and several look out of scope
... worth noting that mez has added some of this material to the future-proofing/PlusOne section of the wiki
... if anyone has issues with any of the proposed dispositions, speak up now
... I propose that we resolve to adopt the recommended dispositions

<tlr> RESOLVED: issues dispoed as proposed in http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html

tlr: no objections, resolved

<tlr> ACTION: thomas to implement issue disposal as described in resolution above in minutes [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action02]

<trackbot> Created ACTION-270 - Implement issue disposal as described in resolution above in minutes [on Thomas Roessler - due 2007-07-25].

tlr: with that, we are down to significantly fewer issues against the note

rec-track document update

<tlr> http://www.w3.org/2006/WSC/drafts/rec/

<tlr> shawn, please speak up

sduffy: all the proposals in template format are now in teh document
... there are a few that don't quite conform, that have been added anyhow
... there is one that I wasn't sure what to make of - BMA browser recs
... nowhere near template format

<sduffy> http://www.w3.org/2006/WSC/wiki/BmaBrowserRecommendations

sduffy: anyone know the state of that

Chuck: I know what it's about - I think Dan started to incorporate some of it with safe browsing mode

sduffy: Okay, safe browsing has been added

Chuck: the BMA document precedes the work of this group, and anticipates a lot of the issues we are tackling. I don't think it was intended as a recommendation, more as a reference document

sduffy: Okay, I can add that as a reference, but it was in the list of recs, so I wasn't sure how to handle it

<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals

sduffy: the ones that still need to be updated are listed in the wiki

<sduffy> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0064.html

sduffy: the other thing to do is re-arrange the document in accordance with Mez' suggestions

<Zakim> stephenF, you wanted to ask about whether tim H's stuff is in that sbm text

stephenF: the safe browsing mode that Tim H was talking about in dublin - did that get rolled in

<tlr> In the wiki: Browser Lock Down (Added to the Editor's Draft - 20070629)

<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals

tlr: Tim H's stuff is called Browser Lockdown, and is a separate rec

stephenF: at some point, someone might say that these things are so similar they should be combined

sduffy: sure, that's possible down the road

tlr: do we have conformance claims for all the included recommendations
... e.g. EV certificates

sduffy: right, that one is listed as needing update

tlr: are there others like that?

sduffy: there are 4 that aren't conforming to the template as a whole, but they vary in where they don't adhere to the template

tlr: my question was, do we have others (except EV) where conformance specifically is missing

<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals

tlr: okay, can you prod the authors of the template-breaking ones via email

sduffy: alright. Quick question - we've had a deadline twice already, to get updated. If they are not updated by this deadline, do we drop them?

tlr: alright, I don't know where RevisitingPastDecisions is lacking, so I don't think we should wait too long, but I think it's worth discussing where they misconform

sduffy: alright, I will call that out in the emails

tlr: and please be clear that if the recommendation is not updated in time, they won't be included
... we don't have a date for the FPWD

tyler: are we going to do the usability-specialist markup and review before FPWD?

tlr: I don't know Mez' plan

tyler: it seems like we should apply our internal expertise before soliciting public comment

tlr: My opinion is that if there is low hanging fruit, I think it should be applied, but we don't want to wait for formal high-quality analysis/research
... hard to talk about it with all four usability experts off the call

tyler: We just risk looking naive, if we don't make meaningful reference to the existing usability work in the field

tlr: As I said, we don't have a solid date for FPWD anyhow, there will be more work between now and then
... next week is a better week to have this discussion than this week

<tlr> ACTION: shawn to prod authors of CertErr, RecRevisitingPastDecisions, EVCert, Letterhead about template conformance; deadline for answers is either this Friday or next meeting [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action03]

<trackbot> Created ACTION-271 - Prod authors of CertErr, RecRevisitingPastDecisions, EVCert, Letterhead about template conformance; deadline for answers is either this Friday or next meeting [on Shawn Duffy - due 2007-07-25].

tlr: I think that's it for the text of the draft so far - anything else?

Self Signed Certificates

stephenF: Let's assume we have consensus around a set of proposals for handling TLS certificates in general
... after that, the question is what to do differently for self-signed certs
... obviously SS certs come with no guarantees - they are a leap of faith - how can that happen without confusing the user, and without opening yourself up to attack
... if you decide that you want to permit it, how do you mitigate the risk
... it's a hard problem, and we don't want to ignore it

<johnathjust to get the conversation rolling ... ... one of the obvious answers ... ... self-signed certs are dead stop ... ... error page ... ... exception: text of the error page could say "if you have good reasons, you can do X to override" ... ... then treat cert as otherwise valid for that domain ... explicitly extend trust ... ... another way of establishing identity ...

tlr: I put myself on the queue to make an alternative proposal
... stephenF mentions the ssh leap of faith
... that is, when you have your first interaction with a site, you learn the site/key association, but on subsequent visits, if the cert changes, noise is made
... if the assumption that "in most cases, your first interaction with a site is legit" is a valid one, then you're basically safe as long as things don't change
... and when they do change, you can behave very attack-detected style of behaviour

<stephenF> I like that first-few-as-if-unsecure idea

tlr: so if there is a downgrade from CA-signed to self-signed, that's an error. But if it is the same certificate presented consistently, we can start to show trust indicators

tjh: I wanted to comment on both proposals
... I don't like the notion of making the user decide, in either of these modes
... it would seem to me that SS certs are something we have to handle, moreso than just "don't use them"

<tlr> for the record, the second proposal does not necessarily make the user pick

tjh: maybe just requiring them to retrieve it out of band

<stephenF> -1 for requiring out-of-band

tlr: jumping the queue to say that my proposal doesn't require user choice up front necessarily

stephenF: I don't like the idea of requiring an out of band interaction
... before you meaningfully improve security, you've already become unusable

tyler: I also think we need a usable answer, I think they're very useful

<tjh> I was thinking more of allowing some "more knowledgeable person" to have procured/installed the "right" SS-Certs

<tjh> and if not there, no-worky.

tyler: I don't like johnathan's proposal - I have heard the opinion expressed that using SSL shouldn't make things worse than HTTP

<stephenF> +1 for that -1

<tyler> http://www.w3.org/2006/WSC/drafts/rec/#piieditor-conformance-association

tyler: tlr and stephenF both made reference to the ssh model, where you only get notified when things change
... if you look at the PII editor proposal, there's language around determining whether "this is the same site I spoke to last time"
... and then the only question is the initial leap of faith
... we need extra care there, since secrets are sometimes passed along in the first interaction

<stephenF> leap-of-faith here for SSCs means we also need to consider notAfter in the past then and now (just noting that so I don't forget so easily:-)

<tjh> I do like the idea of usage of "is this different than before" (history information) in deciding if this is "ok" or not.

<stephenF> good point to propose "safe" entry points to SSC-secured content

<tlr> -1 to that idea

tyler: this means we should consider the kind of URL we'd allow for leap of faith situations

<tlr> +1 to "thou shall have entry points"

tlr: we have 10 minutes left

stephenF: I think the idea of a safe entry points is a good one

tlr: I'm heavily against proposing heuristics to gauge "safety" of a url
... my proposal in that case would be to abstract it a little - "have safe entry points" - don't pass secrets when you have reason

<stephenF> how would I know there's a secret in a URL?

tyler: when site A is linking to site B, it might expect B to be CA-signed. We need the browser to intervene at runtime if it turns out that B is less trustworthy
... microsoft does that today, with their anti-phishing reporting, stripping identifying detail

Chuck: this issue more than others calls out the fundamental issue with how browsers communicate TLS status
... I think we have to be fairly crisp about indicating to the user the difference between having an encrypted session, and having an identified partner
... network appliances use self signed certs all the time, and that's not going to change, it's important to their operation

<sduffy> 12 pm meeting... gotta run... I'll prod the authors of the 4 non-templatified proposals

Chuck: I know it's hard, but it seems like what's needed is a mechanism for pushing certs out to user agents

<stephenF> trust anchor mgmt anyone?

<Zakim> stephenF, you wanted to more-or-less agree with tlr on leap-of-faith and to ask if its really ok to propose that the browser store all certs it sees forever

tlr: cutting chuck off because stephenF has an answer to the current point

stephenF: trust anchor management is something that the IETF has a BoF for next week, which is looking at precisely the topic of delivering trust anchors
... I do like the idea of a growing trust, where it takes N interactions or N days, to establish trust for a SScert
... if we go down this route around spotting changing certs, there are a lot of details to figure out (e.g. expiry)
... that's a fairly complicated bit of context

Chuck: first of all I do wish I could attend the BoF but it seems unlikely

<yngve> old article: http://my.opera.com/yngve/blog/show.dml/461932

Chuck: the point I wanted to make was that there have been a variety of attempts to help users make/manage trust decisions (e.g. Mac OS keychain)

<stephenF> chuck: if you can arrange someone else from an FI to come to the BoF, let me know

Chuck: the problem is, users don't know how to deal with it, and browsers don't communicate it well

<stephenF> just to note that the assumption here is that we've already sorted out the "normal" TLS case

tlr: I think the IdentitySignal recommendation is a piece of that discussions, part might also be about revisiting past decisions

yngve: this is an area where there are probably no good solutions
... what we are probably looking for is the most usable solution. I'm not sure I like either of the existing solutions
... the problem with keeping the history is that you develop lock in, and risk problems during data loss
... posted a link to an article of mine in IRC

<Chuck> Again, in the real world, there are commercial solutions to the problem of local history being lost. For example, syncronization services can handle this problem, and do for many users

tlr: are johnathan or stephen interested in taking up this conversation

stephenF: I'd be happy to work with you on that next week

<tlr> ACTION: stephen to draft proposal for self-signed certs over beer with Thomas [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action04]

<trackbot> Created ACTION-272 - Draft proposal for self-signed certs over beer with Thomas [on Stephen Farrell - due 2007-07-25].

<Chuck> In my case, my history of trusted certs (and password-web site connections) is synchronized across multiple systems, and on a Internet service


<tjh> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/BrowserLockDown

tjh: the overview of this recommendation is to allow for the myriad config settings to be collected into a set of things that makes sense for a given usage case/site list
... so if you have a set of sites where javascript would be fine, you can turn it on, but off for sites where it might be dangerous
... the goal is to greatly reduce the questions asked of the user about security settings
... instead, collective knowledge of security experts can be used to tweak those settings according to browsing mode, which is the only thing that is contingent on the user
... in cases like corporate-deployed browsers, users shouldn't be prompted to change settings, they shouldn't even have the option

tjh - <reads conformance language from wiki>

tjh: a colleague of mine remarked that there ought to be a way to specify whether or not to start in lockdown mode, and should require overt action to break out
... seems like this applies to a great many of the use cases
... one important limitation is the annoyance that users will experience if the configuration is overly restrictive

<Zakim> stephenF, you wanted to ask if this and sbm should be merged (when tim's done with the intro)

stephenF: I like this idea, and I like SBM, but I think they're really the same idea. Should they be merged?

<Zakim> johnath, you wanted to ask, after tjh's intro, whether this is intended to be a voluntary mode or not, particularly for non-corporate use cases

stephenF: it's obviously about setting things like whether to run javascript based on the sites being visited

<tjh> I am open to merging or at least investigating that merge

<johnath> q to tim (might have talked about this in Dublin) -- interpretation of discussion was that it would be nice ... ... to declaratively say "I want to be safe" ... ... didn't realize it would be for instance controlled by admins ... ... or really anything more than basically a big button that says "disable dynamic content" ... ... rules that are downloaded? ... ... not something built in to the browser? .. ... when stephen said these things are the same, took a second to realize why ... ... but if framed in terms of corporate deployed browser, that does sound a lot like SBM .. .. "here's the listof sites, here's what you can / can't do" ... ... "make me safer" button is a different story ...

tjh: I didn't mean to imply a big switch - I use using javascript toggle as an example
... as for corporate - that too was an example
... I tried to bring that out with references to geek squad, or social networking groups

johnath: I am just wondering if this reco involves vanilla out-of-box experience, or only with third-party additions

tjh: I expect that at first it will be purely as an addition, but maybe that evolves over the time

<stephenF> +1 for getting new safe-browsing/lockdown "macros" from wherever (with care of course)

tjh: I expect that users will live in user mode most of the time, and only in admin mode when they are ready and willing to make security decisions

Chuck: the BMA discussions say a fair bit about a need for this
... for a website to put some constraints on how a browser will interact with it
... what is missing is how the website can communicate those expectations to the user agent

<stephenF> just to note that we have the same problem with dkim/ssp and there use DNS

Chuck: right now there's no way for a browser to determine whether a given site intends to use javascript

<Zakim> stephenF, you wanted to ask about level of complexity - is #include <tlr-setttings.h> allowed, what about #define foo bar?

Chuck: I think we should start thinking about practical solutions, even if they're imperfect

stephenF: I assume we are not discussing, though we could, a standard way of expressing these settings-bundles

<tlr> I think that expressing these settings might be a worthwhile endeavour, but likely outside of scope here.

stephenF: I would like to see the settings consider some kind of consistency across browser
... there are issues of complexity here
... which may create problems with composing things, introducing new vulnerabilities, etc

tjh: I haven't gotten as far as figuring out if it's a micro-language, or a database, or a .ini file

tlr: the ability that chuck was hinting at - a way for sites to call out the features they want

johnath: I think WHATWG (?? maybe??) is considering certain limited versions of Chuck's idea, like a header tag to request no script processing, to prevent XSS

Chuck: there are quite a few plugins that do things like NoScript, and per-site security settings - there's a lot of approaches already happening here worth citing

that sounds like action on Chuck to compile a list :)

<Zakim> johnath, you wanted to reply to stephen

<tlr> stephen: Should FPWD have SBM and LockDown separate?

<johnath> might be useful to get separate comments on them, as they might evolve differently ... SBM is whitelist only, to a large extent ... ... LockDown sounds richer ... ... separate issues for public review, unless everybody insists that they be combined ...

<Chuck> I agree with Johnath

<stephenF> counterargument is lockdown seems to include possibility of whitelist ... one proposal included in the other ... ... have some text that points out the relationship ...

<johnath> I hear you ... ... broad reading of lockdown could easily subsume SBM ...

tlr: we're out of time - give tjh final word

<tlr> ... keep them separate, but point out relationship ...

tjh: definitely want to add the bit about current work, mentioned by Chuck.
... fine by me to leave them separate, but agree that there might be language to add

<Chuck> Re: examples, I'd cite the noscript plugin for Firefox as one example, and the OmniWeb browser (Mac only) as an example that allows the user to take an extreme degree of fine-grained control over what a Web site is allowed to do.

next meeting

<tlr> next week, 25 July, MEZ to chair


<tlr> yngve: Yngve @ IETF as well, then vacation & regrets for that time

<stephenF> PHB will probably be in Chicago as well

<tlr> meeting adjourned

issue dispositions for the record

<tlr> ISSUE-78 reassigned to rec-track deliverables

<tlr> ISSUE-79 close without change to Note text

<tlr> ISSUE-80 close

<tlr> ISSUE-81 close without change to text

<tlr> ISSUE-82 reject (and close) since topic was decided

<tlr> ISSUE-84 close without change

<tlr> ISSUE-86 close without change

<tlr> ISSUE-89 close as duplicate of ISSUE-80

<tlr> ISSUE-93 close without change

<tlr> ISSUE-94 close; part out-of-scope, part duplicate of ISSUE-87

Summary of Action Items

[NEW] ACTION: shawn to prod authors of CertErr, RecRevisitingPastDecisions, EVCert, Letterhead about template conformance; deadline for answers is either this Friday or next meeting [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action03]
[NEW] ACTION: stephen to draft proposal for self-signed certs over beer with Thomas [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action04]
[NEW] ACTION: thomas to implement issue disposal as described in resolution above in minutes [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action02]
[NEW] ACTION: tyler to extract changes from ISSUE-6, sort out "prior interaction" confusion, if any [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/07/26 14:56:13 $