WebAppSec WG Teleconference 16-Jul-2013

16 Jul 2013


See also: IRC log


bhill, gmaone, +1.650.488.aaaa, Wendy, +1.714.488.aabb, neilm, +, yoav, mkwst, tanvi, [IPcaller], dveditz
mkwst, dveditz


<bhill2> aha.. so in the "status" window, "/invite zakim #webappsec"

<bhill2> ekr sends his regrets

<wseltzer> [Next call August 13]

Minutes approval

<bhill2> http://www.w3.org/2013/06/04-webappsec-minutes.html

<wseltzer> [for future ref: scribe instructions https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html ]

<bhill2> scribenick: mkwst

bhill2: objections to minutes?

everyone: ...

bhill2: agenda bashing!
... new topics?

Open Actions

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

bhill2: adam and dan aren't on the call. skipping.

<tanvi1> dan may be running late

bhill2: action-127

mkwst: will address both issues this week.

deveitz: hi.

bhill2: dan, how about those open actions?

dveditz: nothing to add since last time.

script-hash proposal

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0003.html

bhill2: responded to that with some items still outstanding.
... moved from 'script-nonce' to nonces as a source expression.
... worth trying the same for 'script-hash'

several folks: yup. makes sense for me too.

bhill2: ni: scheme?
... semicolons are banned, and would need to be encoded (and ugly)
... but it exists, and its something we should look at as they might have already worked out some of the corner cases.

mkwst: verbose and ugly, but worth looking at.

dveditz: aren't hashes verbose and ugly?

bhill2: we could propose an alternate delimiter.

mkwst: where would we propose that?

bhill2: "use the rfc??? syntax with the following modification"

mkwst: seems like a reasonable solution.

dveditz: 'ni' is more like other url schemes, which is good.

bhill2: reusing common conventions.
... sounds like a reasonable place to start exploring.

dveditz: concern about proposal to convert to utf-8 and hash that.
... script is delivered to the browser in some way, can't we just hash what we get?

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html

bhill2: i had the same concern in my reply.
... ^^
... utf-8 is nonpreferred for some languages.

dveditz: lots of text content, but lots of script?

bhill2: inline script === text.

dveditz: hash only for content of script tag, right?

bhill2: what that turns into depends on the document's encoding.
... differences between utf-8 and other encodings.

dveditz: server sends script and encoding, we should trust it.

bhill2: force a document to declare an explicit encoding.
... resolves the problem of potentially rehashing/comparing content.

dveditz: may be difficult for Firefox to get access to the raw bytes.
... we may have to bite it off anyway.
... having bytes come out with different hash because of charset seems wrong. bytes are bytes.

yoav: not reencoding to utf-8 on the browser sounds like the right thing to do.
... error prone.

bhill2: encoding = open question. needs more exploration.
... moving on...
... which algorithms should we support?

<dveditz> yoav was in particular thinking of the problems the server would have trying to hash it according to what it thought a browser would encode it as

bhill2: rfc5920: agreement in code points with webcrypto?
... allow truncation of the hash?
... xml digital signatures did.

<tlr> after a decade

bhill2: don't want to repeat the one-character-truncation problem.
... canonicalization? no?
... might not be in control of the developer. perf. optimizations/transformations.

mkwst: bytes is bytes sounds good.

dveditz: optimizing proxies?

mkwst: mobile operators that optimize whitespace?

<dveditz> transport compression ought to do that well enough, right?

yoav: not predictable. optimizing proxies would need to avoid those transformations.

mkwst: i don't think we should try to support the pagespeed case. code is different when it comes out the other end.

bhill2: next. scripts can have different content-types. vbscript!
... inert inline script with nonexecutable content-type.
... should we include that?

mkwst: what's the threat?

bhill2: valid code in two languages? perhaps far-fetched.

<tlr> comment formats

dveditz: hashes have to be the same. seems unlikely.
... would the text of the script tag remain in the dom?
... just execution, i suppose.

bhill2: yeah.

dveditz: we don't load non-matching scripts for the src case.

bhill2: twitter uses inline JSON.
... still in the spirit of things.
... algorithm agility.
... sha-4? if the browser doesn't understand the hash type, how does it fail?
... what's the failure mode?

dveditz: can't compute a matching hash, will block the ununderstood code.

bhill2: specify sha-1 and sha-3 hashes for script. what should the UA do?
... perhaps only accept the strongest hashing algo. it knows about?

dveditz: what does "strongest" mean.

bhill2: ordering should be left to the UA.
... specify multiple algorithms, but include a hash in each algorithm for each resource?

dveditz: not always the case that multiple hash types means multiple listings for each resource.

bhill2: composing policies might also be difficult.

dveditz: only inline content?
... ni: can include a domain; if we hash loaded content, it would be nice to force usage for performance reasons.
... if you see two hash types, you have to hash all content twice.
... performance issues.

bhill2: if sha-1 is broken, what's the migration strategy?

mkwst: UA sniffing?

<inserted> scribenick: dveditz

<mkwst> <sorry, baby. back in a sec. can someone take over scribing?>

yoav: what's the problemw ith accepting only the strongest hash? wouldn't that avoid the perf penalties

dveditz: the different hashes might be from different sources and cover different chunks of content
... also, which is "strongest"? we'd have to define

yoav: would the policy refer to content ids?

bhill2: I think writing this out and sending it to the list would be the right thing to do here
... any volunteers to improve this proposal?
... neil, can you advocate for this proposal?

neilm: sure

<bhill2> list from: http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html

<bhill2> ACTION neilm to propose updated hash source text to list addressing http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html

<trackbot> Created ACTION-147 - Propose updated hash source text to list addressing http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0004.html [on Neil Matatall - due 2013-07-23].

<mkwst> bhill2: thanks neilm!

mkwst: I don't think the scribe will get my stuff automatically... you may want to cut and paste it back

CSSOM and unsafe-eval

unless there's some magic commands

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0006.html

<mkwst> bhill2: post from ian: ^^.



<bhill2> https://bugzilla.mozilla.org/show_bug.cgi?id=873302

<mkwst> dveditz: we don't block innerHTML, which can be eval-like.

<inserted> scribenick: mkwst

<wseltzer> i|bhill2: thanks neilm!

dveditz: is that a bug?

bhill2: there's a request to do something about that. script-src, innerhtml directive, etc.
... my understanding of cssom is incomplete.
... sounds reasonable on its face.

dveditz: does anyone know of problems that people have had with cssom injection problems?
... if scripts are approved, that might be good enough.

bhill2: no strong opinions on today's call.
... table this, poke the list.


<bhill2> http://webappsec-test.info/~bhill2/pub/CORS/index.html

bhill2: anne won't be editing the spec, licensing.

<bhill2> diffmarked verison at: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FCR-cors-20130129%2F&doc2=http%3A%2F%2Fwebappsec-test.info%2F~bhill2%2Fpub%2FCORS%2Findex.html

<bhill2> (all in email of : http://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0009.html )

bhill2: only ~2 substantive changes.
... change reference to the Fetch spec.
... whatwg spec, not stable, not likely to become stable in the timeline we're looking at.
... CORS shouldn't rely on it. should instead use fetching resources from html5.

tlr: html5 is in cr.
... support changing the reference. will need to talk to them to see if fetching there is stable.
... it's the right step, but talk with HTML after making the change.

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0078.html

<bhill2> add 204 as valid OK status code

bhill2: other change: add 204 as valid status code.
... will need some test code.
... mozilla implemented that, not sure about webkit.
... you get 7 minutes of your life back! enjoy!
... next call in one month, aug 13.

Summary of Action Items

[End of minutes]

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