Web Application Security Working Group Teleconference

29 Jan 2014


See also: IRC log


terri, gmaone, Wendy, freddyb, +1.650.214.aaaa, mkwst, BHill, neilm, ekr, +1.425.234.aabb, ccarson, +1.831.246.aacc, dveditz
bhill2, ekr
Wendy Seltzer


<trackbot> Date: 29 January 2014

<gmaone> Zanon, i am ??P6

<gmaone> wseltzer, thanks, goddamn virtual kb autocomplete :(

<freddyb> Zakim: I am ??p10

<freddyb> The bot wants commas, doesnt it?

<freddyb> bots should listen to people, not the other way around :-)

<mkwst> aaaa is mkwst

<mkwst> Ah, right. I need to talk to Zakim. :)

<terri> should and will are such different things ;)

<freddyb> I propose the use of Universal Greeting Time ;) http://www.total-knowledge.com/~ilya/mips/ugt.html

<hillbrad> :)

<hillbrad> Scribe: Wendy Seltzer

<hillbrad> ScribeNick: wseltzer

Minutes Approval

<hillbrad> http://www.w3.org/2014/01/14-webappsec-minutes.html

hillbrad: Any objections?
... Approved.

Agenda Bashing

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0175.html

hillbrad: Any additions to the agenda?

mkwst: Next steps for moving to last call

<mkwst> wseltzer: that was me

hillbrad: That fits into the CfC results, along with formal objection

Tracker actions

<hillbrad> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

hillbrad: Adam has a number of actions, but isn't on the call

mkwst: I'll take a look at some of the actions

hillbrad: I owe Jonas a note to say we won't do that
... action-161 will prepare new WD with reduced feature set

Integrity and Latency Tradeoffs

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0088.html

hillbrad: initial proposals for subresource integrity envisioned a single hash function
... there was interest in streaming-friendly integrity to reduce latency
... agl proposed unbalanced Merkle trees
... looks as though list consensus: cool idea but hold off for future version
... Anyone think we need stream-friendly integrity in v1?

mkwst: Think it's useful, but pushing off to a later version makes sense
... make sure we're not making bad security choices with integrity overall

freddyb: Agree, it sounds neat, but we don't have a good way to serialize trees

<freddyb> ^-- that was me

ekr: parallel or serial?

mkwst: currently one hash per resource

<freddyb> ^-- that was mkwst

ekr: If we supported multiple hash algorithms, it would be simple to add

mkwst: figure out how to specify multiple integrity checks; should have a syntax for that in v1

<neilm> (sorry, I need to step out for 5-10 minutes)

<hillbrad> one more topic: http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0154.html

hillbrad: should talk about use cases
... stream-friendly opens up some use cases; others don't require streaming, such as content-addressable storage
... Concern raised about attacks on content-addressable storage, latency
... use-case includes local storage for users on low bandwidth connections

mkwst: Don't think that's a crazy use case; but content-addressable storage has properties interesting to attackers
... cache poisoning, timing attacks
... e.g. create a resource with the same hash as jQuery, then replace it in all webpages

<hillbrad> if you can get 2nd preimage, all of the software update mechanisms in the world break

<hillbrad> so your browser gets pwned before jquery

freddyb: also assure it aligns with CSP
... and other origin-based security

mkwst: assure that things introduced into content-addressable storage are public
... access via URL

freddyb: scripts, distinguish between access-control: allow * and include wherever

mkwst: consider how origin-based controls work where origins aren't delivering the resource
... we could be draconian, say if you care about origin, verify before looking at the cache

<ccarson> If the concern is protecting against hash collisions, why not allow webapp to whitelist which hash algorithms are accepted?

<freddyb> ccarson: I don't think this is a main concern, actually.

Length extension

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0170.html

freddyb: might be resolved on list from agl

hillbrad: since we're not using HMAC, no impact

<hillbrad> or rather, a concatenated MAC (HMAC is safe, too)

mkwst: it would be interesting if length could be added to hash

ekr: not sure 2d preimage is substantially harder if lenght is added
... if we need to, should respond with new set of hash algorithms with different properties
... not sure there's a use for generic inputs of functions

mkwst: conversations about ways headers are used; how do we handle mis-matches regarding integrity
... holding off posting before we get done with CSP

hillbrad: also document in spec what properties of hash fns we're relying on; what happens if they fail

terri: describe a plan for how it might work if hash fn is compromised

Beacon and CSP

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0135.html

hillbrad: section describing how properties relate to security can help to preempt future discussion
... Beacon is a new spec allowing for triggering of async post
... what CSP directives should apply?
... 2 camps: connect-src and Form-Action

mkwst: mkwsr don't care so long as it's covered by something
... it can trigger CORS preflight and push arbitrary data to a POST endpoint
... so incline to put it into same camp as XHR. ie connect-src
... if form changes, perhaps make sense to merge form-action with connect-src

dveditz: main reason for including connect-src is because we include data back into document
... connect-src could also be used to block data exfiltration

hillbrad: interesting argument to include beacon as form-action
... only sending data away, not changing document

mkwst: question what you're able to do to external endpoint. Sending to a server that would do interesting things based on your authenticated input

dveditz: it would be great if we could address CSRF
... but likely take a more unified effort than adding things piecemeal to CSP

mkwst: maybe in CSP 1.2
... do we want form-action in 1.1? does it solve a problem we care about?
... is it same as connect-src?
... I think y, y, no

dveditz: I think we care about it, should be distinct from connect-src, but not necessarily in 1.1
... don't want to delay 1.1

hillbrad: document the difference. form-action is data gets sent away; connect-src includes reference to data in document

mkwst: beacon stuff should be included in beacon, not CSP

<hillbrad> ACTION: bhill2 to propose to list text on form-action vs. connect-src re: sending data vs. receiving it [recorded in http://www.w3.org/2014/01/29-webappsec-minutes.html#action01]

<trackbot> Created ACTION-162 - Propose to list text on form-action vs. connect-src re: sending data vs. receiving it [on Brad Hill - due 2014-02-05].

@@: Beacon gives a mechanism for async before-unload

CSP and Fetch

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0161.html

hillbrad: back-and-forth on whether to integrate CSP in fetch mechanism

mkwst: concern that fetch isn't part of W3C
... makes sense to move some of this processing into fetch spec
... but unclear on the politics

hillbrad: I tend to say work should be done where the people willing to do the work are
... don't lose momentum to fragmentation
... keep an eye on it for context and momentum

mkwst: for 1.1, don't think it makes a difference
... for 1.2, think about organization and structure of spec
... to push pieces that make sense to fetch
... Believe we'd define what CSP means, push the policy out as an argument to fetch
... happening in service worker
... we should have more conversations with service worker folks

CfC on new CSP 1.1 WD

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0148.html

hillbrad: Mike issued a call for consensus
... about a week ago. More positive responses than any previous call
... and no objections.
... Unless we have any objections here.
... Unanimous approval to push the WD
... I'll work with W3C to publish (tues/thurs)
... Next steps for Last Call WD

mkwst: I sent a couple emails to the list asking what else we need to do
... response makes me believe there's nothing left
... I think the spec is relatively stable and agreed upon.

<glenn> i'm closing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357, removing Cox' objection

mkwst: the one formal objection aside

[Here's the W3C process: http://www.w3.org/2005/10/Process-20051014/tr.html#last-call]

<glenn> we are satisfied with the resolution; thanks mike

<mkwst> glenn: thanks.

hillbrad: I'd like to be sure we've closed the open issues, even if that's a matter of moving them to 1.2
... we need to formally respond to all comments in LC period

<hillbrad> ACTION: bhill2 give language on how frame-ancestors interacts with XFO [recorded in http://www.w3.org/2014/01/29-webappsec-minutes.html#action02]

<trackbot> Created ACTION-163 - Give language on how frame-ancestors interacts with xfo [on Brad Hill - due 2014-02-05].

hillbrad: so it's best resolve the discussions in the group first
... Ask everyone here to review doc as though it were Last Call doc
... and prepare to move forward within a month

mkwst: working to set up a call with Adam on his actions
... most can be moved to 1.2
... want to look at error-handling on blocked resources
... also 149, talking about blob data
... rest seem push-able to 1.2

hillbrad: that matches reasonably with approach to working with Fetch

mkwst: assume we'll be able to close or push these items relatively quickly

Formal Objection re: user extensions and CSP

<hillbrad> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0165.html

hillbrad: I see in irc that glenn has closed the bug and removed the formal objection
... sounds as though everyone could live with removing the language
... leaving it to browsers to handle extensions

mkwst: some argument from Anne and others that we shouldn't have language that's vendor-specific
... if others aren't happy, we can have more discussion

hillbrad: Can everybody live with that?
... Great

<glenn> thanks

hillbrad: Can everyone live with making that change to CSP 1.0, currently in CR?
... because working on test-suite for script-src, haven't been able to write tests

<neilm> +1

hillbrad: you can make small edits for things at-risk, or that don't pass conformance

mkwst: perfectly happy removing it

hillbrad: I'll make those edits
... AOB?


<neilm> sorry for the keyboard :(

trackbot, end teleconf

Summary of Action Items

[NEW] ACTION: bhill2 give language on how frame-ancestors interacts with XFO [recorded in http://www.w3.org/2014/01/29-webappsec-minutes.html#action02]
[NEW] ACTION: bhill2 to propose to list text on form-action vs. connect-src re: sending data vs. receiving it [recorded in http://www.w3.org/2014/01/29-webappsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2017/02/15 22:32:49 $