Web Application Security Working Group Teleconference -- 21 Jun 2017

trackbot, prepare conference

<trackbot> Meeting: Web Application Security Working Group Teleconference

<trackbot> Date: 21 June 2017

test

lgtm, thanks @wseltzer

thanks wseltzer, still learning my new irc client and it didn't want to change topics

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

hi, JohnWilander, will you be dialing in?

<JohnWilander> (I'm also on the call but I can't remember the cool way of telling you that here.)

<dveditz> what's the diff between that link and https://www.w3.org/2017/05/17-webappsec-minutes.html

minutes approval

minutes approved by unanimous consent

agenda bashing

Signatures in SRI proposal

https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html

<mkwst> https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown

mkwst: hashes exist for SRI, often what you want
... our experience at google has been that hashes are more difficult than expected to maintain
... and use as a deployment mechansim for things that change often
... signatures give a different set of related properties but can be much simpler to deploy
... proposal in explainer document lays out a statement that signatures may be able to solve
... create public/private keypair, public key in integrity attribute, signature over content in header
... dev at dropbox is enthusiastic, rsleevi at google less so
... my opinion is that it offers different things: allows validating trust vs. integrity
... useful for stuff that gets versioned

dveditz: moz folks who've looked aren't keen, worried it will be slow to use
... not sure how it is an advantage over just using tls on the connection

mkwst: with dynamic signing this is not useful, scenarios I am interested in are all offline signing as part of a deployment process
... for things like CDNs

<mkwst> bhill2: <facebook>This seems useful. Roundtrip latency means that the signing key for certs is out as close to customers as possible.

<mkwst> ... CDNs might not be as trustworthy as you might like.

<mkwst> ... Offline signing is useful.

<mkwst> ???: Edge feels similarly to Mozilla.

<mkwst> ... But these sound like interesting scenarios to explore.

<mkwst> bhill2: Also introduces a new kind of primitive that we can use to build useful things later.

<mkwst> ... Strawman ideas for verifiable applications.

<mkwst> ... Know that you're loading the same version of an app as someone else.

<mkwst> ... Tends to rely on some trusted core with a signature-based model.

mkwst: would be great to hear from mozillans that have questions or concerns on list or directly

dveditz: feedback I got was from freddyb, editor of SRI, but carrying from a crypto person in Berlin office
... personally I think it is interesting but official moz position is skeptical
... we do have a kind of home-rolled content signing mechanism for data downloaded into the client, wouldn't have needed to invent our own thing if we had this

mkwst: any docs on that?

dveditz: similar to what Martin Thompson posted

mkwst: would be good to hear a broad thumbs up or down on whether this could end up in the platform with compatible implementations

dveditz: a differnece is whether we know key inherently (for browser content) vs. for any web content

JohnWilander: should we offer the page to pin a specific signature, that looks like today's SRI?

mkwst: also interested in being able to have a policy for a page about what keys to trust

JohnWilander: not interested in pinning the signature?

mkwst: if you want that, you can use a hash now
... not content based
... validating originator of content, not content itself

dveditz: might be interesting to extend to download links

<JohnWilander> (Pinning a signature protects against a hash collision attack but I'm not going to open that can on the call. :)

<mkwst> bhill2: Key rotation is hard.

<mkwst> ... Perhaps we could somehow prevent these kinds of dependencies in some way?

<mkwst> ... Only send signature to certain hosts?

<JohnWilander> (Or maybe not. I have to look at how the signature is made.)

mkwst: rsleevi raised this and there is good discussion on the thread

Compositional CSP proposal

https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0012.html

<mkwst> bhill2: Perhaps some overlap with SRI signatures?

<mkwst> ... Whitelist a key in your policy, allow you to define some interesting extensions.

mkwst: would absolutely expect you'd be able to define a key as a source expression in CSP

<mkwst> bhill2: I wonder if SRI signatures would address similar needs to what compositional CSP aims to solve.

<mkwst> ... They note that 'strict-dynamic' perhaps allows more things than you'd like, as aaj noted.

<mkwst> ... Perhaps composing signatures would get us closer to a good outcome.

artur: my first impression is that if we switched to a signature model you would end up in a similar position to whitelists
... the granularity of signed resources would end up quite similar to the granularity of whitelists, so not sure if it fits with what we are trying to do with the nonce-based side of things

dveditz: in some ways it almost sounds like what they've done is address the objection I had at first with strict-dynamic (which I have been mollified somewhat by the suggestion that one can send two headers)
... might work for a site that knew what they were doing within their own domains

artur: my guess it that starting point for the research was not really the nonce oriented or sri signature angle
... but coming back to original proposals of CSP where author of page is responsible for creating the whitelist
... every author that uses a google widget has to anticipate all the origins from which it may load resources
... goal was to put burden onto the provider of the widget
... if we'd started here in the whitelist world, perhaps ...

(sorry my call dropped, rejoining)

scribe: from where we are, its hard to address

<mkwst> ... folks would be able to whitelist widget URLs, which would set the correct policies for themselves.

cookie changes in Safari

JohnWilander: are there specific questions?

<mkwst> bhill2: There's a lot of value in single-sign on systems.

<mkwst> ... Supplement, replace passwords.

<mkwst> ... "Sign in with X"

<mkwst> ... The changes I'm aware of in Safari will make some of those systems harder to work with.

<mkwst> ... Perhaps discuss what the changes are, discuss how they impact these kinds of systems folks rely on for security.

JohnWilander: with changes that go under name of Intelligent Tracking Protection
... there should only be website data and cookies for sites that the user "uses" currently defined as a user gesture
... those cookies should only be available in a 3rd party context for sites that the user uses often
... we did think a lot about the single sign on cases, which is a reason why there is a 24 hour window
... where you can interact with an identity provider, e.g. example.com, so example.com will be available as an identity when you go to a new site
... not ideal, we are building on existing web behavior and APIs
... would like to get to a situation where sign on is two different things
... which is why we have been talking about what we've called associated domains
... which would allow related sites to exempt themselves within the scope of one organization from these restrictions
... because SOP is not an accurate reflection of the real state of things in terms of what domains are the same organization
... the other case is where unrelated organizations want to do SSO
... would like to come up with a way (help from this group?) to come up with a way, like a user gesture, to ask for permission to access cookies in the 3rd party context
... if there is a user gesture in a frame that has maybe a social plugin, that would allow for the true 3rd party to ask for permission to use it's cookies
... and we could remember and allow that to happen

mkwst: in terms of the way this is being deployed, it would be useful if there was better debugging
... waiting a day is not great
... and I think devtools in webkit is not showing the partitioned cookies for a request, only 1st party or no cookies in cases where it should show partitioned cookies
... we will file bugs to help you give developers the data they need to make this work
... larger question I have is about 2nd order effects of removing cookies from things that developers can expect to have on the web
... it seems to me the goal of this feature is great
... in an ideal world, ensuring that data is present on a user's computer when that user is interacting with the owner of that data
... seems like a reasonable goal
... a problem is that cookies are not the only mechanism that exists, and a benefit is that users have control and are aware of those controls
... the statement I would make is that the folks that you would like to prevent from tracking users are unlikely to be completely deterred from tracking users
... and it may create an impetus in the market to move to tracking users by means over which they have less control
... and I am concerned that we will end up worse than status quo, both in terms of "ickiness" in what will be done and lack of user control
... curious what you think about these second order effects and how these will play out
... and if there are plans to combat these effects

JohnWilander: are you talking about stateful thing or stateless things, known as fingerprinting

mkwst: let's assume you've taken care of all stateless stuff
... folks will move to fingerprinting

JohnWilander: this has come up as we did research and implementation of the feature
... our position is that even though there are other ways to achieve some level of tracking we are not going to shy away from trying to do something about the things we know are being abused today
... we are going to monitor what happens, new ways to track will be invented
... and take it from there.
... if all move to fingerprinting, we will move focus to anti-fingerprinting

anti-fingerprinting may be easier for apple to do than others

JohnWilander: if fingerprinting is great, why are we seeing trackers use stateful mechanisms?

mkwst: I think people use the mechanisms that exist because they exist because they have very high levels of correlation
... and they have user controls understand

JohnWIlander: we realize that stateful mechanisms are the golden standard and that's why we go after them
... user control is part of the feature - we believe the user shows intent by interacting

<mkwst> http://www.scitepress.org/DigitalLibrary/PublicationsDetail.aspx?ID=UoE90ECay/Q=&t=1

future agendas

mkwst: origin attributes paper from Mozilla
... we are interested and enthusiastic, a good topic for the future

http://www.scitepress.org/DigitalLibrary/PublicationsDetail.aspx?ID=UoE90ECay/Q=&t=1

<mkwst> \o/

<ArturJanc> congratulations!

<JohnWilander> Congratulations, Brad!

bhill2: would be nice to see a proposal for user consent gestures from Apple at TPAC

mkwst: and site affiliation stuff

artur: origin attributes and suborigins could be good to discuss again next month with feedback from mozilla

trackbot, end meeting

- DRAFT -

Web Application Security Working Group Teleconference

21 Jun 2017

Attendees

Contents

minutes approval

agenda bashing

Signatures in SRI proposal

Compositional CSP proposal

cookie changes in Safari

future agendas

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output