WebAppSec Teleconference, 13-Jul-2016 -- 13 Jul 2016

<jochen___> then we should be good to move forward

<jochen___> thank you :)

<jochen___> then I'll repeat what I just said..

<wseltzer> you might send email, for broader visibility

<jochen___> oh, I just saw this specific question on the agenda that Brad sent around

<jochen___> I don't think it's particularly urgent

<jochen___> anyway, about Referrer policy moving forward

<jochen___> I'd like to add some text about CSS and referrers

<jochen___> now that we have the referrer policy header, I think we're in a good place where we can spec this

<jochen___> once that's done, we can move forward

<jochen___> EOM :)

<wseltzer> botie, inform bhill2 jochen left some notes on irc earlier, http://www.w3.org/2016/07/13-webappsec-minutes.html

<botie> will do

<botie> bhill2, at 2016-07-13 15:38 UTC, wseltzer said: jochen left some notes on irc earlier, http://www.w3.org/2016/07/13-webappsec-minutes.html

can do

agenda bashing

<mkwst> bhill2_: Sent out a call for agenda items, put together some topic from the last month and a half.

<mkwst> ... Anything I missed?

<mkwst> Everyone: <crickets>

minutes approval

https://www.w3.org/2011/webappsec/draft-minutes/2016-05-17-webappsec-minutes.html

https://www.w3.org/2011/webappsec/draft-minutes/2016-05-16-webappsec-minutes.html

<mkwst> bhill2_: Objections to approving these minutes?

bhill2: any objections to unanimous approval?

<mkwst> Everone: <crickets>

<mkwst> bhill2_: Approved.

transition of some specs to WG NOTE

<mkwst> bhill2_: We put things on the board at the end of day 1 of the F2F.

<mkwst> ... Came up with a list of things we might want to transition to NOTE.

<mkwst> ... CfC expires next Friday.

<mkwst> ... This basically means that we're not taking them towards REC. Just archived for historical purposes.

<mkwst> ... FPWD retains some IPR if we resurrect them (and we can, this isn't irrevocable).

<mkwst> ... Cookie Controls was the first one.

<mkwst> ... Mike suggested that Feature Policy might be a better home.

The Feature Policy proposal (

https://wicg.github.io/feature-policy/) could be a better home for the

intended functionality as part of a broader and more coherent approach,

rather than putting this into CSP.

<moneill2> q

bhill2: would clear site data be also under feature policy?

mkwst: I see it as distinct because it operates on the storage for an origin and not just a page / resource
... enough interest that it's worth continuing in that

<mkwst> tanvi: Is feature policy done by WebAppSec?

<mkwst> bhill2_: Currently in incubator group. WICG.

<estark> ^ tanvi? wasn't me

<tanvi> yeah, that was me

mkwst: don't have a target group at the moment, Chrome puts ideas into incubation before looking for a group
... when we are far enough along and have enough experience we think about where to move it
... my impression is that web perf is interested but also some overlap here, no strong opinion
... folks here and in web perf should be taking a look at it and there are a number of places it might life

moneill2: about cookie controls; one of the points of CSP was it allowed use of set-cookie headers in embedded resources
... feature policy only gives control over javascript accessing document.cookie

mkwst: the only thing that would affect embedded resources is the embedded enforcement mechanism that we are investigating for CSP
... which says you will only embed a frame if it accepts certain policy

moneill: but the CSP cookie controls allowed managing cookie headers for images, etc.

mkwst: it didn't and we didn't get far enough in specifying it; would suggest you look at Feature Policy, and we should consider how to handle that
... document will suggest a policy that denies a certain thing for a set of origins, please file bugs against that as we might be able to support these features there

moneill2: meta tag in CSP was ruled out for feature policy, would be good to have that back as it is quite useful for content served by e.g. agencies
... easier to have a library that can insert a meta tag than control headers

mkwst: good convo to have on the incubator group / github repo for feature policy

bhill2: any other concerns with stopping this work here?

Entry Point Regulation

https://www.w3.org/TR/epr/

<mkwst> dveditz: Mozilla supports pushing this to NOTE.

<mkwst> bhill2_: Will ask drx to follow up on the list.

<mkwst> ... At F2F folks seemed to feel that the SameSite cookie work at the IETF took care of much of the same threats that EPR wanted to address.

<mkwst> terri: Sad to see it move to NOTE, but accurate, as no one is working on it.

terri: sad to see it moved to note but accurately reflects where the effort is

CSP Pinning

https://www.w3.org/TR/csp-pinning/

<mkwst> bhill2_: We probably need something like this, but this probably isn't the right mechanism.

<mkwst> ... Costs to sending a default policy with all requests.

<mkwst> ... Platform needs a more general mechanism.

<mkwst> ... .well-known, manifest, etc.

<mkwst> mkwst: I agree.

Referrer Policy to PR: What is needed?

https://github.com/w3c/webappsec-referrer-policy/issues

<mkwst> bhill2_: Missing states we discussed at F2F have been added.

<mkwst> ... What's left?

<mkwst> estark: Three items left:

<mkwst> ... 1. Updating web platform tests: header and new policy states.

<mkwst> ... 2. Finish the HTML integration for the `referrerpolicy` attribute and new policy states.

Jochen left this note in IRC earlier: https://www.w3.org/2016/07/13-webappsec-minutes.html re: CSS

<mkwst> ... 3. Jochen wanted to do something for stylesheets. Process headers delivered with stylesheets for resources loaded via the sheet.

<mkwst> francois: I'm planning on doing some of the items Emily just mentioned.

<mkwst> ... New policy states to WPT and to HTML.

<mkwst> ... Fetch also.

<mkwst> ... That's all I think is needed.

<mkwst> dveditz: Two of the issues are in the 11 open issues for the spec.

<mkwst> dveditz: Perhaps we could invent a label for those issues in the repo so that we know what we need to get done.

<francois> https://github.com/w3c/webappsec-referrer-policy/issues/50 is the issue for finishing the work around the new states

<mkwst> dveditz: Just want to distinguish between editorial changes and big normative issues.

<mkwst> bhill2_: Meta-goal is to get specifications ready to go before TPAC, then I can poke at various folks about Fetch and HTML integrations.

<mkwst> ... That seems like a good forcing function to get resolution on these questions.

Mixed Content to PR

Should we allow localhost?

https://github.com/w3c/webappsec-mixed-content/issues/4

mkwst: 2 things: 1: align with secure contexts spec definitions; this has implications that 127.0.0.1 should not be considered mixed content
... because by going over loopback vs. network has same / similar security properties to something transiting the internet on a secure channel
... 2: other issue is the name 'localhost' vs loopback address
... there are some cases where localhost or *.localhost will hit the network for resolution, so would suggest we can't give it the same a priority secure designation
... as the loopback IP addresses
... suggestions on the list were to align the document and update such that the name localhost doesn't have the same definition as loopback addresses

tanvi: should we do the second one first? or will we be decreasing security before increasing it?

mkwst: we are doing both at the same time in Chrome in Q3/Q4; I've landed for 127.0.0.1, have to check on localhost

ccowan: is this going to land with localhost CORS requirements as discussed at F2F?

mkwst: that is a bit more work and so I'm doing the one first, the other will take a bit longer

ccowan: as long as they're not incompatible in a sneaky way

mkwst: what this allows is folks to stop installing certificates for localhost which is an unalloyed good, later stuff will compose

ccowan: sounds great

tanvi: I'm ok with this change.

dveditz: +1

UIR with fallback

<terri> I'm even excited about this change: it should make it easier for some of our engineers working on protype hardware

https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0012.html

dveditz: he's proposing we do upgrade and if it fails, retry?
... are redirects upgraded as well?
... so we'd have to retry each half-loop potentially?

mkwst: I think we can work out these details
... I understand why Peter likes the idea and the value he perceives
... but we don't have any other mechanism in the platform that does something like this
... so we have to do the work to invent that mechanism
... this is problematic even for doing preflights for things like images as part of RFC1918 CORS
... to support this at all we would need to do a request and start a new one that is tied to the old one and triggers all the same effects
... this could be possible and there could be real value but not sure the effort would be justified
... I do like the idea of magically turning it on and making one class of mixed content less prevalent
... but don't think could implement in the near future, though that shouldn't be a gating factor on what we specify

tanvi: christophe doesn't think this is that difficult, but not super easy either, need justification and people asking for it

mkwst: peter's request is interesting on behalf of Let's Encrypt as a novel way to automate https upgrading
... but also agree with brad that mixed scripts decrease that value

tanvi: some may be broken

mkwst: claim made was that it couldn't be automatic, would still need to be verified live after flipping the switch
... opposed to allowing mixed scripts

<tanvi> yeah i wouldn't allow mixed script

tanvi: you're right, it would help some sites and not others and require testing

mkwst: interesting, has potential value, but not sure state of the world would allow it to be as automated as LE would like to do it by default
... and with that, not sure the rearchitecting for the fallback would be worthwhile.... but that is colored by my understanding of the difficulty of implementing in Chrome

tanvi: our perspective at mozilla is to wait on this until we hear from websites that this would be really useful to them

bhill2: maybe Peter can give us some data by simulation.

mkwst: would also be interesting to know if a SW can polyfill this for origins we know about
... add something to UIR that lets a ServiceWorker fill in with insecure content

bhill2: would still be opposed (with FB hat on) to allowing active mixed downgrades, need to know that redirecting user to https means https

Changing window.name behavior

https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0006.html

mkwst: seems reasonable to do what Artur suggests, clear on navigation as the spec says (but no browser actually does)

dveditz: believe that is for non-auxilliary windows, popups with names need to be targeted

mkwst: don't recall seeing that in the spec, but may have missed that
... I think it is a reasonable thing to do regardless of what the spec says. Chrome doesn't clear it at all in any case.
... would like to measure how often it is used and throw it away if low enough
... but probably doesn't solve any XSS vectors because there are other sources
... less inclined to break back compat because of that
... doesn't appear that any Google bug bounties used window.name as a vector

<mkwst> bhill2_: Perhaps restricting character sets might be possible.

ccowan: if you restrict length, you will only break good applications, not malicious vectors

dveditz: not interested in changing charset or length, would break as much as flushing
... would be nice to flush if data shows we can do it without breakage

mkwst: planning on adding metrics to next version of chrome (54) will hit stable in 12-18 weeks

CORS for developers: adopt as WG note?

https://docs.google.com/document/d/1AtxTDw-g9BSRW9n9kGTTqNkDTGcVfSKPAOjVGkPFu2k/edit#heading=h.gbk9567omrcz

interesting to publish as a WG note?

mkwst: I think so yes, would like to see more developer facing documentation from this group in general
... both historical explainers and how-tos

terri: agree, would like to do more in this area

<mkwst> bhill2_: TPAC is coming.

<mkwst> ... In Portugal.

<mkwst> ... Our slot is Thursday and Friday.

<mkwst> ... After the AC meeting.

<mkwst> ... Maybe everything with Fetch, etc will be resolved already!

- DRAFT -

WebAppSec Teleconference, 13-Jul-2016

13 Jul 2016

Attendees

Contents