See also: IRC log
<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
<hillbrad> http://www.w3.org/2014/01/14-webappsec-minutes.html
hillbrad: Any objections?
... Approved.
<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
<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
<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.
<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
<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
<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
<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
<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?
[adjourned]
<neilm> sorry for the keyboard :(
trackbot, end teleconf