Create 2024-11-20-minutes.md

meetings/2024/2024-11-20-minutes.md

@@ -0,0 +1,174 @@
+# WebAppSec - 2024-11-20
+
+**Logistics**
+
+*   **Minutes**: <https://pad.w3.org/p/WebAppSec_2024-11-20> (Use your W3C credentials)
+*   [Add these events](https://www.w3.org/groups/wg/webappsec/calendar#export) to your calendar
+*   **`#webappsec`** on [W3C's slack instance](https://w3ccommunity.slack.com/)
+    * <https://www.w3.org/slack-w3ccommunity-invite> if you haven't already joined.
+*   **Zoom**:
+    * Details at <https://auth.w3.org/?url=https://www.w3.org/groups/wg/webappsec/calendar>
+
+## Attendees
+
+* Mike West
+* Artur Janc
+* Kristian Monsen
+* Emily Stark
+* Benjamin Ackerman
+* Ciara McMullin
+* David Dworken
+* Daniel Veditz
+* Victor Huang
+* Lukas Weichselbaum
+* Gal Weizman
+* Simone Onofri
+* Yoav Weiss
+* John Wilander
+* Aaron Shim
+* AnneVK
+
+## Draft Agenda
+
+[Wednesday, November 20th: 16:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20241120T1700) (09:00 California, 12:00 Boston, 17:00 London, 18:00 Berlin)
+
+### Draft Agenda
+
+*   [Device Bound Session Credentials](https://github.com/WICG/dbsc) updates and next steps (@kmonsen)
+
+*   [Subresource Reporting and CSP](https://github.com/yoavweiss/subresource-reporting/issues/4) (@yoavweiss)
+
+*   CSP Issue Triage updates (@ciaramcmullin, et al)
+
+*   @annevk suggested we discuss `Last-Event-ID`: <https://github.com/whatwg/fetch/pull/1788>
+
+*   [Post Quantum Cryptography for XML Signature and XML Encryption Suites](https://github.com/w3c/strategy/issues/484): During IETF 121, we discussed Post Quantum on XML, and we're thinking of having a workshop. Is it the case to include Web Crypto in the workshop? (@simoneonofri)
+
+## Minutes
+
+### [Device Bound Session Credentials](https://github.com/WICG/dbsc)
+
+kmonsen: Presented this last year, want to update. Joined forces with Microsoft, they've added enterprise bits to the explainer. We've gotten feedback on GitHub, thankful for that. Prototype with Google, trying to understand fesiability. Closing in on featute-complete. Aiming for two origin trials, first focused on functionality, then another focused on reliability (assuming the first goes well). Is there interest in adopting DBSC into webappsec? We talked to IETF as well, but feel that this is a better place for the work. Would aim to get adopted here, but present into IETF. Hoping for more community participation.
+
+mkwst: [said things that were positive; might need to recharter? Useful and important. Might need to figure out the relationship to Cookie Layering.]
+
+simone: Working on it. Will figure out the process for adopting from WICG.
+
+dveditz: Clearly thematically fits into our WG, need to figure out IPR around the agreed-to scope in our charter. Agree that it sounds like the kind of thing that fits in the group. Can rely on W3C staff to help with process.
+
+kmonsen: We've reached out to WebKit and Mozilla. Mozilla lacks bandwidth, sees login as more important problem to solve. Talked with folks at WebKit at TPAC.
+
+mike: CfC to mailing list seems like the right next step. We can work out process afterwards.
+
+### [Subresource Reporting and CSP](https://github.com/yoavweiss/subresource-reporting/issues/4)
+
+yoav: As part of the PCIv4 requirements we talked about at TPAC, there's the necessity to create an inventory of the scripts executing on your documents, as well as their integrity. Debates about what that means in practice, but ideally the platform would provide developers with the ability to ask the browser for a list of all the scripts executing on their page, and their content hashes (assuming CORS-enabled). Exploring the problem space, I put together a Subresource Reporting proposal. ddworken suggested it would be neat to integrate this into CSP. Not initially excited about that, as the point in time at which reporting happens is different: currently at request time, but this needs to be at response time. That said, there's a desire to unify the API shape so that we can also report non-subresource hashes with the same mechanism (`eval()`, etc). Is that the right direction to go in? Adds some complexity into CSP, but generally fine. There's a spec sketch in the repo, not super-complex, just more moving parts.
+
+dveditz: Same-origin policy violation. Learn about cross-origin scripts folks get based on who they were signed in as. Could we restrict to CORS?
+
+yoav: This is restricted to CORS. Is limiting hash reporting to CORS not enough?
+
+dveditz: No, that's satisfactory.
+
+estark: How are you thinking about non-CORS-enabled resources. If the requirement is to get an inventory of all scripts, you wouldn't get non-CORS resources.
+
+yoav: From a deployment perspective, it would require us to make sure everything is CORS-enabled. Will ask partners politely to do that. If not sufficient, it would be nice in any event to have some kind of document policy to enforce CORS on all outgoing requests. But for reporting here we'll know which URLs don't have CORS enabled, can go tap folks on the shoulder to get those taken care of.
+
+mike: Pre-redirect URLs, right?
+
+yoav: Right.
+
+anne: Is CSP used because you need a mechanism to opt into this?
+
+yoav: This all relies on reporting API.
+
+anne: Doesn't CSP have its own reporting mechanism?
+
+yoav: Yes. But would only attach this to `report-to`.
+
+anne: We would only support one of the proposed mechanisms?
+
+yoav: Just one; originally wanted a new header, but there's interest in integrating into CSP.
+
+anne: SRI integration in CSP already.
+
+ddworken: Why it's nice in CSP: SRI, but also hash-based CSP. Most good CSPs use script nonces, but we'd like to help developers use hash-based policies. To do this, we need to report hashes, this feature would be dual-purpose: integrity and XSS mitigation.
+
+yoav: Other concerns?
+
+anne: Other kind of SRI, with request headers (?). Does that change the exposed information?
+
+yoav: What's the proposal?
+
+anne: Signature-based SRI.
+
+yoav: Signing the response header.
+
+anne: But there's a request header in that proposal as well.
+
+yoav: Hashes are just response content hashes.
+
+anne: Could we expose more information here.
+
+ddworken: Signature-based SRI has request headers. Browser sends a header saying "we want a signature to be attached to the resource". But we don't need this here, we just need hashes for response bodies.
+
+anne: If there is a request header, server might be assume that the information is protected by a hash. Now there could be a dictionary attack?
+
+ddworken: CORS is still a requirement.
+
+anne: The server could use the presence of the request header with something. 
+
+ddworken: Could be weirdness, but it's the server holding the API wrong.
+
+anne: Sec-Fetch headers are used as a security boundary.
+
+ddworken: That's how they should be used. But that's not the purpose of the headers / signature-based SRI.
+
+ddworken/yoav: Maybe discuss this in a spec issue? https://github.com/WICG/signature-based-sri. @Anne: Can you open an issue to discuss this more? 
+
+mike: RFC allows headers with signatures.
+
+###  CSP Issue Triage updates
+
+ciara: https://docs.google.com/document/d/1FQQ5Hxdh7V9v62zL6nHOz2nAFOVeWC_wYphzDs8Zv0I/edit?tab=t.0#heading=h.7nki9mck5t64. Based on dveditz's suggestion, we set up labels, should add them to the repository and start using them. Using the same ones as WHATWG.
+
+annevk: In WHATWG, "good first issue" has resulted in more spam than helpful input.
+
+ciara: Thanks for that feedback. I'll add these labels, and set up some additional conversations to drive the triage process.
+
+dveditz: Social place to meet? IRC? Slack? If you have thoughts about where to have a backchannel.
+
+mkwst: We created the Slack channel for TPAC. I'll check it more often.
+
+### `Last-Event-ID`: <https://github.com/whatwg/fetch/pull/1788>
+
+anne: Add Last-Event-ID to the CORS safelist, retrofit semantics to the eventSrc object, which currently sends the header cross-origin regardless of value/length. Would make EventSrc more secure and patch hole in SOP. Currently what browsers do is they bypass CORS restrictions and tack on the header after the CORS check is made. The only concerning thing is that there's a UseCounter in Chrome and the trend is rising - now 0.008% of page loads end up hitting the restriction. In the future they would get CORS preflights, which could result in breakage. If everyone coordinated, we could likely land this.
+
+artur: What's the header purpose/value?
+
+anne: Server sends you a stream of text with k/v pairs, strings. One of the pairs is ID with a value of an arbitrary string. U+0000. That string is UTF-8 encoded and if the UA has to reconnect to the server, it will include the last ID value in a subsequent request. What can happen is the server can redirect to another origin and it will get replayed there.
+
+artur: So the consequence is sending this header with an arbitrary value?
+
+anne: Can't send \xFF, there are some restrictions. But can send other data. With new restriction it would be possible.
+
+yoav: You mentioned 0.008% pages are hitting that, it would be good to split that between triggering a preflight vs. failing the preflight. Then we can talk about breakage vs. performance regression. 0.008% isn't a lot. If breakage is 1/3 of that, it's probably fine for Chromium. If this is trending up, might be good to take action now. Chromium folk should split the UseCounter.
+
+artur: Wouldn't it be tricky to trigger a preflight?
+
+yoav: Could do a Finch experiment in Chromium, or a dud preflight to see if it passes or not.
+
+dan: Doesn't Last-Event-ID currently trigger a preflight if you use it? 
+
+anne: Does in normal Fetch. But it does not trigger a preflight with the EventSource API and that gives you blanket access to this header and can send a lot of values. Given that the API can do it, Fetch could have the same capability as long as the restrictions are the same as the ones used for the accept header
+dan: Conclusion? 
+
+anne: Call for comments on the PR, will try to move ahead with spec changes, see if it gets adoption.
+
+###  [Post Quantum Cryptography for XML Signature and XML Encryption Suites](https://github.com/w3c/strategy/issues/484): During IETF 121, we discussed Post Quantum on XML, and we're thinking of having a workshop. Is it the case to include Web Crypto in the workshop? (@simoneonofri)
+
+simone: ^. Should we think about PQC WebCrypto? Can discuss on the GH issue.
+
+dan: Almost certainly PQC will have to be integrated in WebCrypto eventually
+
+mike: Figure it out on GH?