WebAppSec Teleconference, 19-April-2017 -- 19 Apr 2017

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0028.html

agenda bashing

no new suggestions

dveditz notes that there is discussion on list of serializing of suborigins, but right people probably not on the call today, better left to list and github issue discussion for now

<jochen___> we still don't have two implementations of everything

<estark> Chrome doesn't have 3 of the policy values implemented

<jochen___> yes!

<jochen___> and estark :)

<jochen___> Firefox needs to implement the CSS bits

next steps for referrer policy

estark: still need to implement new policy values and firefox needs to do css things

rechartering

approved, https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0042.html

please ask your AC rep to re-join

UISecurity to NOTE status

dveditz: no objections on list or call so time to complete this

COWL spec update

deian: on implementation side, hired someone to work on the implementation full time, would like to bring him to work on the spec too, if possible
... Abdul, a masters student started hacking on the chrome implementation a few weeks ago, want to talk to chrome team about exposing behind a flag
... still refactoring after talking to Eduardo about his isolation proposal, a bigger overhaul than I thought it would be
... in original spec, top level pages could drop privileges even if they couldn't be tainted
... now that's no longer possible so you can only do interesting things in iframes, in long run this may be better as covert channels are less in out of process iframes
... if someone can help me bikeshed it in the next few weeks that would be nice

bhill2: to clarify on bikeshedding? actual discussion bikeshedding?

deian: yes, as in we are talking with Eduardo, so we are looking for design review on use cases, etc.
... would be nice to have a uniform way to interpose on postMessage the way we have with Fetch, since this is needed for suborigins as well

<jochen___> currently trying to refactor how suborigins hooks into postMessage: https://github.com/w3c/webappsec-suborigins/pull/67

<jochen___> comments welocme

deian: would also be nice to extend the secure contexts notion to be able to disable certain features / APIs in a confined iframe similar to as with http

<ArturJanc> for disabling certain APIs in COWL world maybe you can lean on the Feature Policy

deian: one thing we'd like to do is not allow websockets, for example, since overhauling to work with information flow seems like too much for now
... I should look at feature policy

bhill2: working on Chrome you say, still working on Firefox?

deian: yes, a little slower, there is a team on CMU working on it

<jochen___> \o/

bhill2: might be interesting to find a way to have a more extended discussion with COWL, Suborigins, Feature Policy teams about common mechanisms for these different approaches
... let's propose that kind of meeting on the list to try to illuminate the core platform features that these things have in common

Upgrade Insecure Requests spec update

mkwst: this will be relatively short, not much of an update
... on chrome, we are upstreaming tests to WPT
... we've also found one issue that Emily is working on, we are not doing CSP reporting correctly, should be reporting before but are reporting after
... patch in place that should land relatively soon, similar with redirects
... I think we have interoperable implementations
... we should verify that, but from a spec POV we are good and should move to PR once we have tests to back up that

devditz: does spec expect reporting to be synchronous?

mkwst: (summarized) we want CSP to be useable for detecting links that are not upgraded, while also supporting automatic upgrade
... so reporting and enforcement are separate steps

dveditz: I'm reasonably sure that in Firefox the reporting and blocking are bound up in the same code

mkwst: in a lot of our tests we rely heavily on the DOM event so we don't have to go up to the server, but that doesn't work so well in firefox
... it would be really good to get that event implemented so we could more easily write reusable tests for WPT

dveditz: I keep trying to make that a priority but it unfortunately isn't at the time
... anecdotally, we got reports of someone who can't login to an old linksys router due to upgrade insecure requests, but somehow chrome works fine

Credential Management

mkwst: we've had robust conversations recently with the WebAuthN WG to bring FIDO work into a web-facing API

<dveditz> in this particular case it didn't kill the gear, Firefox lost a user

mkwst: we're coming to the conclusion that it would be good if WebAuthN was structured as an extension of the CredMgr spec
... we've rewritten it in a way that doesn't change it for developers but makes the extension mechanism more clear
... and more useful for the types of extensions that would be useful for WebAuthN and other things people are thinking about
... we've made some API changes
... user mediation is now an enum vs. a boolean
... previously allowed for potential of UI, but not required mediation
... now you can do silent, potential UI but accepts silent, and a require user mediation as policy states for that
... we also added an async constructor for all credential types, new create method to navigator.credentials
... need this for WebAuthN because they can only be created in an async fashion by talking to an external device
... also gives user agents an opportunity to interject and do things like password generation while interacting with the user, which requires an async mechanism
... navigator.credentials.create will return a promise
... Domenic is probably on call and manages password mgr

domenic: we've had some reports of usability issues around use of Fetch
... some website expect a JSON object, others process passwords before sending it along
... by not exposing the credentials this is broken, and hiding the credential from the website doesn't provide that much extra security in XSS scenarios
... e.g. by switching form fields. After discussing with our security team, cred mgr API is a path forward to stronger credentials and it is good to make this sacrifice against XSS protection
... in order to move the web forward faster towards better credential types by by not hindering adoption of cred mgr with this restriction

JohnWilander: question about javascript access to credentials, could that be done by registering a function to apply without exposing it

<deian> cowl :)

<dveditz> :-)

<jochen___> the other problem was that ppl weren't able to change the server side

(can someone help the scribe with the proper spelling of the speaker's name, I was attempting to crib from irc nicks in the room and got it wrong)

mkwst: passwords are bad and we want to get rid of them, better to help users use password managers and better credentials than trying to protect use of passwords from XSS
... as lcamtuf noted in postcards from a post-xss world, it's totally possible to exfil data, fixing those seems for now more costly than it was worth

JohnWilander: betting on passwords going away doesn't seem like it will happen before I retire
... especially with two-factor, there will still be a password and then something else

mkwst: yes
... webauthn has the notion of authenticators that are first factors in and of themselves
... you can imagine something more capable than a security key today that could use biometrics or magic that can provide identity in addition to device and user presence
... even if you don't buy that, I still think that the goal of increasing the usability of password managers is a win
... they are defended against phishing in ways that are more important that defending against content injection at legitimate sites

<mkwst> JohnWilander: https://github.com/w3c/webappsec-credential-management/pull/76 <--

JohnWilander: can we discuss on the list this particular tradeoff? so it is recorded

mkwst: see that pull request
... we have a model that works for the credentials we know about today, but want to think about and get feedback so extension points support things we may want in the future
... more eyes would be super helpful

<wseltzer> PR 384, Strawman of an integration between WebAuthn and Credential Management

mkwst: more eyes from WebAppSec on that PR would be awesome

<mkwst> bhill2: Edge 15 released.

late agenda bashing

<mkwst> ... CSP2. Nonces! frame-ancestors!

<jochen___> and unprefixed Web Auth (?) cf jakob rossi

<mkwst> ... Crispin Cowan left Microsoft. We should encourage MS to continue their engagement with this group.

<mkwst> plh: I can help with that. Happy to poke people.

fb.me/recovery

<mkwst> bhill2: Credential recovery mechanism launched recently.

http://fb.me/recovery

<mkwst> ... https://fb.me/recovery

<mkwst> ... This seems like a more secure solution than other recovery mechanisms out on the market today.

<mkwst> ... Would love to work with other companies!

(spec is at: https://github.com/facebook/DelegatedRecoverySpecification)

mkwst: would like to resurface discussions about associated origins

<battre> https://developers.google.com/digital-asset-links/v1/getting-started

mkwst: both apple and google have ways to do this for credential sharing
... would be interesting to figure out if there is appetite for doing things like that more broadly
... is there a cowpath to be paved here?
... seems like there is some level of commonality

mike, there is also this from FIDO days: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

<battre> https://developer.apple.com/reference/security/shared_web_credentials

mkwst: also prior work in DBOUND, so =JeffH would want to discuss
... though it seems like what apple and google have come up with is pretty different

dveditz: possible interest at Moz, we keep building and disbanding password manager groups as priorities change

qa/

JohnWilander: I do think it's on me to continue the thread I started
... should probably fork off the whole thread on shared credentials

agenda for next call

<jochen___> I'm here

dveditz: Suborigin has had active list discussions lately

mkwst: jochen has taken over for joel, seems like talking about it next month would be a good idea

<estark> I've been meaning to send around a rough spec for Isolate-Me (wicg.github.io/isolation/index.html), maybe if we put that on the agenda for next time it'll force me to actually send it out

bhill2: I think dev ususally has a conflict with this time, but maybe we can give him enough notice or give everyone else enough to shift this call an hour or a day if needed to get both him and jochen on the call

dveditz: clear site data?

<adrianba> we still have people from Microsoft who are members of this group - i'll figure out who is going to pick up the engagement from crispin

<dveditz> thanks, adrianba

<deian> thanks all

<mkwst> wseltzer: https://www.w3.org/2017/04/19-webappsec-minutes.html is throwing a 404. Does RRSAgent just take some time?

- DRAFT -

WebAppSec Teleconference, 19-April-2017

19 Apr 2017

Attendees

Contents