diff --git a/meetings/2024/2024-09-23-TPAC-Minutes.md b/meetings/2024/2024-09-23-TPAC-Minutes.md new file mode 100644 index 00000000..2a2e8778 --- /dev/null +++ b/meetings/2024/2024-09-23-TPAC-Minutes.md @@ -0,0 +1,365 @@ +WebAppSec @ TPAC 2024 - 2024.09.23 +================================== + +Attendees +--------- + +* Mike West (Google) +* Dan Veditz (Mozilla) +* Ari Chivukula (Google Chrome) +* Paul Zuehlcke (Mozilla) +* Simon Pieters (Mozilla) +* Matthew Finkel (Apple) +* Marian Harbach (Google Chrome) +* Carlos Ibarra Lopez (Google Chrome) +* Mike Taylor (Google Wave 👋) +* Aaron Selya (Google Chrome) +* Joe DeBlasio (Google Chrome) +* Anna Weine (Mozilla, remote) +* Chris Fredrickson (Google Chrome) +* Sanket Joshi (Microsoft) +* Siye Liu (Microsoft) +* Camille Lamy (Google Chrome) +* Emily Stark (Google Chrome) +* Dominic Farolino (Google Chrome) +* Kyra Seevers (Google Chrome) +* Simone Onofri (W3C) +* Simon Friedberger (Mozilla) +* Dylan Cutler (Google Chrome) +* Nick Doty (CDT) +* Balazs Engedy (Google Chrome) +* Shivani Sharma (Google Chrome) +* Anusha Muley (Google Chrome) +* David Dworken (Google) +* Lukas Weichselbaum (Google) +* Chris Thompson (Google Chrome, remote) +* Daniel Huigens (Proton) +* Bumblefudge (Protocol Labs) +* Robbie McElrath (Google Chrome) +* Siye Liu (Microsoft) +* Artur Janc (Google Security) +* Hiroshige Hayashizaki (Google Chrome) +* Sasha Firsov (Web Components, XML/XSLT groups) +* Domenic Denicola (Google Chrome) +* Aaron Shim (Google) +* John Wilander (Apple WebKit) +* Johann Hofmann (Google Chrome) + +Agenda +------ + +* **9:00 - 9:15**: ☕ and agenda bashing. +* **9:15 - 9:45**: Crypto + * (~15m) Web Crypto (@twiss) + * Algorithms (modernizing, post-modernizing) + * Curve 25519 + * Streaming + * Feature Detection + * (~15m) [Remote cryptokeys](https://github.com/WebKit/explainers/tree/main/remote-cryptokeys) (@marcoscaceres, @estark37) [Try to move this to Thursday.] +* **9:45 - 10:30**: Application Integrity/Transparency (@ddworken) + * (~25m) Extensions to SRI + * Additional content types + * Additional assertion types ([signatures](https://github.com/mikewest/signature-based-sri), etc)) + * `require-sri-for` (@yoavweiss) + * (~20m) Signing / Packaging +* **10:30 - 11:00**: ☕ & 🍰 @ [Lanai Deck, Fifth Floor](https://www.w3.org/2024/09/TPAC/schedule.html#map) +* **11:00 - 12:00**: CSP + * (~15m) Should the threat model include exfiltration? (@yoavweiss) + * (~20m) How can we improve adoption? (@simoneonofri, @johnwilander) + * Docs & recommendations? + * [CSP Next](https://github.com/WICG/csp-next)? + * (~15m) Could we [require injection mitigation](https://mikewest.github.io/injection-mitigated/) for interesting APIs? (@mikewest) + * (~10m) What's left before putting CSP into "living CR" mode? +* **12:00 - 12:10**: https://github.com/w3c/webappsec-permissions-policy/issues/273 (@siliu1, @sanketj) +* **12:10 - 12:30**: **Breakout pitch session**. There are a number of breakout sessions ([grid](https://www.w3.org/2024/09/TPAC/breakouts.html#grid), [details](https://www.w3.org/2024/09/TPAC/breakouts.html#intro)) on 25.09.2024 that are relevant to this community. Let's talk about them a bit so folks can plan accordingly. + +Crypto +------ + +* Daniel: + * Curve 25519 + * Good news! All implementations have shipped Ed25519: Still behind a feature flag in Chrome. X25519 is getting there as well. + * Less good news! Impl of ed25519 isn't exactly the same in all implementations. Safari shipped a randomized varient that's proposed in IETF, but no RFC yet. Still a bit of discussion about how to refer to the RFC or the draft in the WebCrypto specification. It wasn't discussed at IETF, but reached out on mailing list and informal conclusion is that there's not yet concensus about what the `Ed25519` name should mean: randomized signatures or not? + * Proposal: refer to EdDSA as defined by "RFC8032 or its successors", and adopt a formal change once the RFCs are done. + * Other minor details. Might be niche incompatibilities we should work out. + * Questions: + * Javier: We've been talking about this over the last few weeks. How to prevent the issues raised for merging the PR into WebCrypto. Is the current proposal enough to unblock that? Apple was looped in to approve the PR. Does that align with our needs? https://github.com/w3c/webcrypto/pull/362 + * Daniel: Anne? Opinions? + * Anne: Hard time hearing. + * Daniel: Explaining references: is it sufficient? + * Anne: Probably OK, but language is not specific enough to write tests against. Might be better to simply leave an issue marker in the spec, or put it in a note. The general idea of "the current RFC and its successor" makes sense, but need to guide testers and implementers. Might not be consensus, but I don't think changing the name is an option at this point. + * Daniel: Seems like it's still up for the IETF to decide, but agree that just leaving an issue about it in the spec is probably fine. + * More modern algorithms: + * Mozilla expressed interest in SHA-3. Other algorithms folks have expressed interest in. + * Modern Algorithms draft: move to WICG? + * Mike West: Moving to WICG seems like the right next step. Post a link, we can provide expression of interest. + * https://github.com/twiss/webcrypto-modern-algos (for now) + * Post-Quantum Algorithms. Could add to that draft or make another. + * Matt Finkel: Developer interest in these? + * Daniel: Several were asked for on WebCrypto's issue tracker. Argon2 (better key derivation function), SHA3, ChaChaPoly. Others were added to round out the offering (kMAC, etc). + * Matt: Higher-level interface than `.subtle`? + * Daniel: Yes. David Benjamin from Chrome was interested in adding HPKE. Ben Beurdouche from Mozilla as well. Not sure if in this draft or a separate, but would make sense. + * Feature Detection: + * `subtle.crypto.supports()` function can be used to check whether an algorithm is supported. Might be too late given the support for curve 25519 in Safari, et al. Already need to try/catch. + * Does it make sense to add a function for feature detection for additional algorithms in the future? Ideally all would be implemented, but would be helpful to developers to have explicit detection. But maybe try/catch is enough? Maybe we're too late? + * Anne: If try/catch works, then I don't think we need it. For other things, like testing dictionary members, the work is even more complex, but we still endorse it. If we're just removing try/catch, it might not be worth doing. + * Daniel: Testing support for options when passing the algorithm identifier dictionary: might want to specify option for deterministic or randomized variant of ed25519, might want to know about support. Try/catch, plus manual inspection of whether the browser did what you asked. + * Anne: With try/catch and an frozen options dictionary should be doable. + * Daniel: Ok, might not be a good idea. But the pattern you're suggesting seems convoluted. Other APIs have `supports()`. + * Anne: Motivated by not being able to use that pattern. + * Mike Taylor: The try/catch egronomics are pretty crappy. If we can provide an API, that seems better. I agree that the current pattern exists, but it's not intuitive. That said, not specific to this API. Generally, ergnomicis are better with an API. + * Anne: Should we design that on a per-API basis? Should be generic? + * Mike Taylor: If you want to solve the generic problem, great! On the point of it being too late given Safari's support, I'd generally say no. If we agree that the API would be better, we should ship it and it becomes less of a problem over time, and hope that Safari ships it as well. + * Simon Pieters: Unknown values in the dictionary. Shouldn't it throw if you pass in an unknown value? + * Daniel: We generally ignore. + * Simon: No, if the key's supported with an unknown value, we'd throw. + * Daniel: Yes. + +Application Integrity +--------------------- + +* David Dworken: Integrity for the Web [slides link TBD] + * Web vs. Native apps. + * Native has a single bundle, signatures, potentially strong guarantees of integrity and transparency. + * Web is more dynamic runtimes. No entire-app integrity, no transparency between users. + * Because of this gap: + * Applications like Signal don't exist on the web. They've looked at the threat model the web offers, and can't find a way to reassure users that this class of E2E applications are running the code they expect. + * Folks are implementing polyfills to try to make this work. Extensions like CodeVerify that check application bundles for a website. Has to be an extension, compromises made because it's not a web platform native API. + * Many subresources can't be checked by SRI today. + * Google Analytics is dynamic, doesn't fit static hashes well. + * ES Modules, Service Workers. + * Supply chain risks. + * What if the web tried to solve this? + * Talking with some developers about this. It'd be nice if we could address it. + * Goal is to solve the Signal problem, while also making it possible for smaller applications to progressively deploy integrity checking. Early ideas floating around. Looking for broader thoughts on the problem. Is it a problem worth solving? + * Ilya G: PCI requirements for checkout. IFrame was a suffiicent security perimeter for PCIv3, doesn't work for PCIv4. It's a problem for a large population of ecommerce sites. + * David Dworken: Let's talk about some of the early ideas we have: + * Want to aim for solutions that offer strong integrity. + * Goal is to design something that can solve these problems, but also smaller scoped problem. + * Intermediate milestonres: + * SRI with Signatures + * SRI for more resource types + * document-level `require-sri-for` + * origin-level `require-sri-for` + * Committed origin-level `require-sri-for` + * Nick Doty: Earlier, you suggested integrity meant same code delivered to each user. Important problem, but not the entire problem. Might be forced to deliver malicious code. Could deliver it to everyone, which would still be bad. Would be nice to have some sort of trust/review representation. + * David: Right! What if we could offer stronger transparency? Something like CT for application code. Possible to see the application code logged: this is the bundle that clients saw. Might be possible to audit those bundles. Further down the road. The ecommerce use case doesn't need this full solution, but if we think about it now, it might be possible to solve in the long run. + * Nick Doty: This adds value in the ecommerce case too. + * Ilya: Right now we're looking at this for dynamic cases, no solution. + * Emily: Is Shopify's need for hash-based SRI for more resource types? Or is signature-based necessary? + * Yoav: I don't think there's a need for more resource types. We care about JavaScript. Regarding signatures: that seems very useful. Seems like a good way to validate that a party we trust is the one providing the code. + * Emily: PCI security requirements would allow signatures? + * Ilya: Not a PCI compliance expert. Something of a moving target. Want to defend parent page, but requirements shift depending on who you talk to. Deploy a crawler, fingerprint all the resources on your page, say that's your app. Would be ideal to know which resources are loaded and their content. + * Yoav: Ideally, we could have signatures and hashes. + * Emily: Just wondering if signatures are plausibly useful. Sounds like yes. + * Chris Thompson: To Nick's point about integrity: at some point do we need some form of versioning? Strongest versions of protections here would allow users to not automatically upgrade to the next version. Signature-based SRI doesn't allow pre-auditing, just validates source. That's perhaps a stepping stone, but is there a path to something that has versionions more deeply embedded. + * David: Seems plausible to me. Aiming for maximal security, non-automatic updates could be useful. But pretty far down the road, more pressing problems. + * Benjamin: New WG at IETF: Keytrans. Might be useful for this, anything around CT for non-certificates. Latest draft from mcmillion, working with Signal, seems like it's going in a good direction (https://datatracker.ietf.org/wg/keytrans/about/). https://datatracker.ietf.org/doc/html/draft-keytrans-mcmillion-protocol + * Robbie: Two different solutions here. Stronger SRI and CT-style log. For the latter, need to know all the resources ahead of time. For Signal, the model is that the server can't be trusted. SRI doesn't address that use case. Is SRI shorter-term, lighter-weight? + * David: Yes. Long-term goal might allow some sort of committed, origin-level SRI promise. Might allow to defend against malicious server. + * Yoav: 1st party origin? + * David: Yes. But true that more immediate milestones, verifying just this one third-party resource would be useful. + * Robbie: In the transparency approach, that would not just be subresources, but also the main resource? + * David: Yes, would need to address all of that. + * Daniel Huigens: Supply Chain Integrity Transparency Trust (SCITT) WG at the IETF. Mentioned this there as well, they seemed to be interested in working on this as well. (https://datatracker.ietf.org/wg/scitt/about/) + * Emily: We talk about this as "Signal on the web", but Signal hasn't been super explicit about whether this is what's blocking them. So we should be looking for intent from other developers, not overindexing on Signal. + * Daniel: My understanding is that they've said this at some point, though a while ago. Proton is strongly interested in this use case. Other applications as well that could benefit. We tend to focus on applications that use E2EE as being the sole use case for this, but others: any web application that does all its work client side. Note-taking app: Still want guarantees about behavior, like "doesn't send notes to the server". + * Matt Finkel: A few variants of this. In earlier discussions, concerns about the threat model. If we're trying to provide something similar to integrity/authenticity of native apps, that excludes some of the lighter-weight proposals. + * David: I'd agree. We'll bring actual proposals with a real threat model. + * mkwst: small things that don't address the whole problem can still be very useful + * Ben Goering: Mastodon. People want to fix DMs. But client-side encryption on the web has this same problem (for example, https://github.com/w3c/tpac2024-breakouts/issues/89). Signal-aside, the W3C social-sphere would be interested here. Crypto wallets too. Integrity could help. Breakout! + * Camille: +1 to Mike. Several different threat models, different solutions that address them. New web apps might need the bigger threat model, while existing apps might benefit from smaller stepping stones that add integrity in important places. Those might not evolve into the larger threat model ever, but would still be ideal to address. + * Yoav: Is there appetite for `require-sri-for`? This would be very useful for the commerce case. Could potentially help elsewhere as well. This was removed from Chromium in ~2020 because modules and workers? + * Dan Veditz: Also dynamic scripts like Analytics. + * Yoav: Fair. Modules were fixed. Workers still don't have it, but not relevent for our specific threat model. For the dynamic case, it's tricky to deploy, though it's possible to think of a design in which versioned URLs could help. Shopify's use case is mostly for `report-only`. Would help us understand when scripts change. Would be even better to expose hashes as part of the report. Does that sound reasonable? + * Dan Veditz: Sounds like a reasonable request. Might need a discussion of making reporting better for CSP generally. + * [Artur and Yoav to chat about similar proposals.] + * Aaron Selya: Auditing. Would you expect a failed audit to surface something to users? Break the application? + * David: No answer yet! Let's figure out how to do the audit before determining what impact it has. Maybe similar to TLS errors? Out of scope at this point. + * Dan Veditz: Reporting as well. + * Emily: CORS requirements for SRI: is that not a deployment blocker for Shopify? + * Yoav: For the scenarios we have in mind, it's a reasonable request to the third-parties. Could be a deployment hurdle at large. But we should make CORS easier; if that turned out to be an issue at call sites, a document policy to force CORS requests would be helpful. + * Dan Veditz: Sites that supply libraries should already provide the script with CORS headers, but shouldn't be hard to convince. + * Artur: We require CORS for SRI because you could otherwise detect the hash of content. Signature-based SRI might remove that problem, as there's no longer one version of the code. + * Mike: signature-based SRI has an inherent server opt-in, which might make this problem easier (either the signature opt-in could itself serve as a CORS opt-in, or at the very least, the server operator already has to do something so they can set CORS headers too) + * Dan: How would signature-based SRI work? + * David: `