<scribe> scribenick: dveditz

<mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2018May/0003.html

Agenda Bashing

<mkwst> jeffh: cross-origin framing of webauthn-wielding origins

<mkwst> dveditz: Goals for TPAC.

<mkwst> dveditz: Scheduled for only one day. Is that enough? Should we fight about it?

Minutes Approval

https://www.w3.org/2018/04/18-webappsec-minutes.html

mkwst: anyone object?...

News

mkwst: hearing no objections minutes are approved
... SameSite cookies shipping in Firefox, appears to be impl,emented in webkit but not yet shipping
... exciting!

<jeffh> https://www.w3.org/TR/webauthn/

mkwst: WebAuthn spec has moved to CR. shipping now (yesterday) in Firefox 60, upcoming Chrome 67 and Edge 17
... dropbox added support. great to see

jeffh: we demo'd this at RSAC with Firefox and Chrome against live PayPal (not rolled out to customers yet)

mkwst: can you roll it out to my account please? I'd like to be a trusted tester

jeffh: exciting to see, a major milestone

mkwst: any other news?

dydz: I implemented samesite cookies, have a question about the spec. Syntax says you can send just "samesite" without a value but the latest spec removed the sentence on how that behaves

mkwst: we had a fairly recent change to the spec that FIrefox folks pushed through
... invalid values are ignored, and a misisng value is considered invalid

<mkwst> https://github.com/httpwg/http-extensions/

<mkwst> https://github.com/httpwg/http-extensions/

dydz: but there's [another section] that says an invalid value is treated as strict. where do I file a bug?

mkwst: I'm sure there are still bugs in the spec. love to have bugs filed, love even more to have PRs that fix the bugs

<jeffh> https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-rfc6265bis.md

jeffh: clarifying question. there are a bunch of specs there, are we talking about 6265bis?

mkwst: yes

dydz: you also have a test site but it shows everything as broken

mkwst: we have upstreamed that now to WPT thanks to the Firefox folks. don't think it's exhaustive but it's better than what we had before

dydz: I'll take a look at that. that runs online?

mkwst: yes? but I don't know if it supports everything we need such as a second domain yet (one has been registered, may not be done)
... please do test and file bugs

CSP

<jugglinmike> dydz: find me in #testing if you need help running WPT locally

<jugglinmike> Though the readme should have you covered :)

<dydz> jugglinmike: Will do

mkwst: from last call y'all talked about hashed attributes, inline attributes, and versioning. I think other vendors were going to look at the docs and give andy feedback
... did anyone? [crickets]
... please please read and give feedback

AndyPaicu: this is an explainer about adding unsafe-hashed-attribute keyword, has a bunch of uses such as static pages
... can allow inline handlers without having to use unsafe-inline which is worse for security
... still unsafe (as in the name) but less risk
... mostly useful for style which has far less powers as attributes than inline
... there are two solutions and looking for feedback for which is the best idea
... 1) server version mechanism, not particularly exciting [header name?]
... 2) would be new directives for csp3-compatible scripts/style which old clients will ignore

dydz: from a brief look, one of your proposals would be script-src-csp3 -- is that only for these new keywords or would that support the whole gamut
... open question -- have you considered the perf implications of this feature given event handlers tend to show up in lots of places in a page?

AndyPaicu: not sure what you mean by perf -- the event handlers are already checked against script-src

dydz: but we're not doing any hashing. this will require us to do that

AndyPaicu: don't think this has been tested

ArturJanc: short answer-- most pages that require inline event handlers have a fairly small number of them (2 - 5)
... current csp supports hashes for inline script and we have seen pages with dozens and haven't noticed a perf problem

johnwilander: I don't think we're on the right track to make csp useful and successful -- it's growing in complexity.
... the driver is mostly sites the complexity and resources of google is driving this, but it's not particularly useful in general

mkwst: I generally agree with you. csp not widely deployed by orgs that don't have a large scale like Google or Facebook etc
... helping those orgs does have high impact because lots of users and lots of content
... I also agree CSP is very complicated and I'd like to make it simpler. we had a proposal maybe 2 years ago for a simplified form

<mkwst> https://github.com/mikewest/artur-yes/

<scribe> ... new header (joke Artur: yes). but more seriously a simplified form with a single simplified threat model

mkwst: my opinion is csp3 should be the last csp and we should do something going forward

johnwilander: that means we're going to spend time on this and it'll be a while, another two years with no good answers for developers with limited resources

mkwst: I disagree. Artur and team have recommend a simplified form that should be simple to deploy for people who don't have a complex legacy site
... i agree that csp is too complex, but I don't think it stops people from using it effectively today

johnwilander: I worry we're spending our precious time polishing and adding complexity to csp3 when we should be looking to make a difference to security to the web not jus the big sites

AndyPaicu: my biggest concern is sites that use 'unsafe-inline' because that's what makes their site work. the protection is useless in that form
... 87% of sites using CSP have that!
... the unsafe-attribute form will help some of those sites be more secure by limiting their use of unsafe

<johnwilander> Thanks! I'm silent to not spend more time on CSP3. ;)

mkwst: we should talk more about this, and I agree, John, that we should be careful how we spend our time. Please look at Andy's proposal and give him some feedback

Cross-origin data leakage

mkwst: lot of activity in the cross-origin data leakage space

jeffh: just to point outthe item I sent about web payment and webauthn and framed powerful features fits with this topic

mkwst: my understanding of your concerns was it was about clickjacking and ??, not so much about leakage

<mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2018May/0009.html

jeffh: you may be categorizing problems differently than I do

mkwst: I'd like to talk about your concerns too

ArturJanc: document is not long, please take a look. 1) most of the discussions we have about leaks have focused on Spectre
... spectre is a damaging attack but it's only one way leakage has caused damage. I liked 7 or 8 different kinds of leakage in the doc
... Majority of them affect real world applications. I think we've had 4 or 5 in our own applications in the last month
... second thing it does, reviews the mechanisms we've discussed in the past month and see which of them address which classes of leaks
... main goal is to think broader problems than just spectre attacks
... doc doesn't advocate for a particular solution, but if we solve the bigger problem developers will be more inclined to use them than if we just address one specific threat (like spectrea)
... Complexity of csp has been on my mind. one of its original sins is it took a browser view of the world than an application view of the world. switches to control individual resources the browser thought about (scripts, style, images). Would like to think about it from the applications view so we can address those threats more simply

mkwst: yes, please look at the doc
... one of the stategies Artur looked at is From-Origin. John would you like to expand?

johnwilander: this is an old proposal (2012?) an http response header where the server says what context they'd like to be loaded. Sometimes the server doesn't get context data. values are "same", "same-site" (eTLD+1) -- checking all the way to the top. Open question on whether it should do that or let CSP frame ancestors do that.
... also open question whether there should be a list of allowed not-same-site origins
... simple, easy to understand. browsers can implement this and sites can get protection much faster than they can get site isolation going (except chrome which is far along that path)

mkwst: sounds like anne is proposing we fold this into CORB somehow
... the question is whether htis affects framing or whether XFO/frame-ancestors should be used along side
... opinions on what the goals of this should be?
... who is going to be making decisions about what this should do? Would be helpful if there was an explainer doc rather than just a github issue thread. I think anne was going to but may not in practice. Can anyone else take a stab?

johnwilander: I'm not going to sign up to do that, but I think my implementation in webkit can be taken as my proposal. We have 35 testcases we could convert to WPT once we agree on the behavioe

<mkwst> https://github.com/whatwg/fetch/issues/687

jeffh: is the functionality John landed different than the note Anne wrote up? (the 2012 note)

johnwilander: different in a couple ways.
... only supports "same" (schem+host+port) and "samesite" (eTLD+1, ignore port and scheme).
... in addition, enforces on the entire frame chain

mkwst: my concern is that when browsers implement this they implement the same thing. tests are great, prose is nice too
... the github issue pasted above is useful, but also confusing. need a simplified description that ultimately anne can fold into fetch spec

ArturJanc: also useful -- some of the choices that seem equivalent might affect whether it's adoptable quite a bit.

dveditz: can you give an example of the small differences that make a big difference?

ArturJanc: john mentioned the frame ancestors thing, and also whether it's simply the two options given or has a whitelisting ability
... in my experience devs will want to load this in one place for an entire application.

mkwst: let's cap this here and bring it back to github

<mkwst> `sec-site`: https://github.com/whatwg/fetch/issues/700 / `sec-metadata`:

<mkwst> https://github.com/mikewest/sec-metadata

mkwst: other proposals Artur evaluated linked here

<johnwilander> There's also the Cross-Origin-Options header.

mkwst: Jeff -- can you talk about the concerns you had?

jeffh: if you take a look at the frame handler spec, all these cross-origin issues apply even apart from from-origin spec
... checkout on a site: ux folks want the payment instruments (cross-origin) to be seemlessly framed from the user's POV
... but these handle powerful features like authentication and payment. what's the security of cross-origin framing here

mkwst: this relates to the payment handler spec and the choices made in the credMan spec. one of the choices we made int he latter was that only the top level could ask (or same-origin frames)
... reasonable question how we can expose useful features to subframes, in a way users can understand and trust
... we need to figure that out because there are use-cases, but I have no idea how to do that

stpeter: [big topic, we're running out of time to discuss here]