Create 2023-10-18-minutes.md

meetings/2023/2023-10-18-minutes.md

@@ -0,0 +1,169 @@
+WebAppSec WG
+============
+
+[Minutes from previous meeting (TPAC 2023)](https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-TPAC-agenda.md)
+
+Attendees
+---------
+
+* _You?_
+* Kristian Monsen (Google)
+* Peter Zenzerovich (Microsoft)
+* Olga Dalton (Microsoft)
+* Sameera Gajjarapu (Microsoft)
+* Arnar Birgisson (Google)
+* Philippe Le Hegaret (W3C)
+* Mike West (Google)
+* Abdulrahman Alqabandi (Microsoft)
+* Daniel Huigens (Proton)
+* Ian Clelland (Google)
+* Gerhard Oosthuizen (Entersekt)
+* Aleksandr Tokarev(Microsoft)
+* Anshuman Goel (Microsoft)
+* Anne van Kesteren (Apple)
+* Zandré van Heerden (Entersekt)
+* Jun Kokatsu (Google)
+* Artur Janc (Google)
+* David Dworken (Google) 
+* Lily Chen (Google)
+* Dan Veditz (Mozilla)
+* Simon Friedberger (Mozilla)
+* Will Bartlett (Microsoft)
+
+Agenda
+------
+
+* Folks from Microsoft and Google will present proposals around cookie theft mitigation:
+  * [Device Bound Secure Credentials (DBSC)](https://github.com/WICG/dbsc/)
+  * [Demonstrating Proof-of-Possession in the Browser Application (BPoP)](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/BindingContext/explainer.md)
+* Small announcement: [Source Code Transparency](https://github.com/twiss/source-code-transparency) [Explainer](https://github.com/twiss/source-code-transparency/blob/main/explainer.md) and [WICG Proposal](https://github.com/WICG/proposals/issues/124)
+
+Minutes
+-------
+
+### Charter
+
+plh: Going to kick off the process.
+
+(now follow the charter at https://github.com/w3c/strategy/issues/426 )
+
+
+### Cookie Theft Mitigation
+
+#### DBSC
+
+[Slides](https://docs.google.com/presentation/d/1AIaWMf75CU12sW-zNPfUUcc8jj5oCAqAlr5m_BYRhoI/edit#slide=id.g2414b7992ab_0_0)
+
+kristianm: "What is DBSC?" <https://github.com/WICG/dbsc/>
+
+...: Hope to make this a web standard, allowing websites to securely bind session authentication to a single device. Should be more secure than cookies.
+
+...: Cookie theft is a problem. <https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/>
+
+...: Problem for the web in general. Many effots in Google on cookie theft, DBSC is one of many, we hope it can contribute.
+
+...: Requirements: Goal is that attackers cannot obtain long-lived authenticated access without access to device-bound key. Should work for existing cookies/infrastructure. Primary threat model is compromised devices.
+
+...: Non-goals: preventing abuse via on-device malware.
+
+...: Aim to leverage device-bound cryptographic keys. TPM support on Windows > 60%. Basic functionality: private key that _never leaves secure chip_.
+
+...: But, TPMs are _slow_. >500ms for signing. Can't sign every HTTP request.
+
+...: Planning to periodically exchange a proof of posession. Periodically exchange TPM-backed key for short-lived token. Similar model to OAuth.
+
+...: Aiming to resuse existing web technology. JavaScript, HTTP Headers, Cookies, reusing existing app logic, JWT between client and server.
+
+...: [Diagram showing the basic exchange pattern of cookies vs. this mechanism]
+
+...: Interested in feedback on design. JavaScript vs headers, etc.
+
+...: Continued diagrams detailing the flow. Same as https://github.com/WICG/dbsc/#start-session.
+
+...: `navigator.securesession.start(...)` explainer.
+
+...: Refresh explanations. See https://github.com/WICG/dbsc/#refresh-procedure.
+
+...: Many details. Multiple concurrent sessions? Yes. Sharing keys between multiple sessions? No. ...
+
+...: And open questions: cross-origin, cross-site? First-Party Sets? (now "Related Website Sets"). HTTP Headers vs JavaScript API? Ad hoc one off signatures? Etc.
+
+####  BPoP <https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/BindingContext/explainer.md>
+
+[Slides #TBD](#TODO)
+
+Sameera: Complementary proposal. Use cases are similar to DBSC. Our motivation is mostly based on DPoP, token binding. Also try to cover cases in which only certain subdomains are bound.
+
+...: Also header-based solution. When session is established for a website, we want to piggyback on that.
+
+...: Walking through https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/BindingContext/explainer.md#detailed-example
+
+...: Want the standard to specify enterprise cases. Each platform has its own model: want the flexibility to support these. Enterprise policies help with this.
+
+Will Bartlett: We do want to address malware on the device in our threat model, unlike DBSC. We also want to reduce roundtrips on first-run experience. Sharepoint could activate BPoP as part of the redirect to an identity provider. Would be ideal from a perf perspective to do the same.
+
+kristianm: For the consumer case, malware on the device is outside our threat model. We do try to prevent malware from being installed after the fact.
+
+Will: For enterprise users, we have a policy structure. For consumers it's more complicated. Perhaps need to ask users to activate such features. Device owners could enforce.
+
+Sameera: 
+
+Aleksandr: In both proposals, I don't like the ideas that we're separating enterprise users and provide lower quality. MS or Google could change proposals to register browser at moment of log-in. Then use similar algorithms to prove that the key for this application was generated on this device. Would like identical quality between consumers and enterprise. Google debating internally whether GMail and YouTube should have the same key.
+
+kristianm: We don't want sessions to be tracked across sites. But there should be a possibility for something like first-party sets to assert two sites are controlled by the same server, not sure how to do that yet.
+
+Aleksandr: IDP sites, similar goals. By their nature they're already sharing common information. Google/YouTube, MS has similar. Admin/device owner/something else can say "This site is special, trusted IDP", with more flexible algorithm that protects consumers.
+
+Arnar: Why YouTube and google.com. We do things to make sure you're signed into the session in both places. Malware can force you to do a lightweight sign-in to YouTube by selectively deleting one session but not the other. Important to have some ability to ensure that device binding is also consistent.
+
+...: Goals of the proposals are the same. One important difference: we've tried to do things like this at Google. Very hard to change everything at once across multiple products, stacks. This is why we introduced the refresh endpoint. Try to add the binding on the backchannel, then rely on short-lived cookies which fit into all the existing infrastructure. Possible to support a system that does everything in one header, but balancing a flexible API with something simpler that verifies the next round trip.
+
+Sameera: BPoP wants to use existing OAuth pathways. Will use the same calls that they make to bind a cookie. So isn't a new endpoint actually a new implementation in the stack rather than a browser build API that would do the binding? Possible to have the API generate a key that says "This is my broker, this is my platform, etc." or a key for a consumer use case. That should be a one-time operation, and the second would bring a nonce from the website that's trying to authenticate the cookies and refresh that. Need more discussion.
+
+Arnar: Tying to what the key could mean in enterprise context is a thing we can do without too much additional complexity. Not mentioned in the proposal, because the whole thing is a heavy lift. Can leave it to the user agents in the consumer case. On Linux, with no hardware facilities, it's ok for the UA to do it in software.
+
+...: If we have elements in this that require developers to make updates to all their apps and frameworks, it gets in the way.
+
+Sameera: Need to write code either way.
+
+Gerhard: We help banks with authentication. Getting a replacement for fingerprinting is important. We're evaluating both proposals. Due to the world of payments in which we work, the framed context is important. Merchant A and Merchant B frame the bank, need to know it's a returning user. Perhaps through Storage Access or Payment Request, etc. Maybe worth adding as a requirement.
+
+...: Active challenge pattern. WebAuthN initiates a user-visible challenge. Did the team consider creating a new type of authenticator that could be silently challenged? Could be a bit closer to the web community already using WebAuthN. Is that something you've looked at?
+
+Will: WebAuthN has been built as deep feature in JavaScript, prompts, etc. Cookie Binding is more foundational, shouldn't hide behind browser privacy prompts. WebAuthN could evolve to be something that's both behind prompts and not, but seems like having two things.
+
+Arnar: I'm also deeply involved in WebAuthN/FIDO. Folks have considered this path. Two reasons I agree with Will that it's better to separate:
+
+...: 1. WebAuthN is very focused on user-interactive sign-in. User chooses where to store their keys. Password managers, passkey managers, etc. Lots of complexity that's not relevant to this space, programatically binding cookies to devices.
+
+...: 2. If we go the silent WebAuthN route, it's similar to things we've tried where we add an API that's very simple for the browser, but difficult for developers to integrate. When do they do that? Where do they inject the JS to do that? Apps or IDP? Different kinds of requests? What do you do when the authentication is required? Can't hold things on the client side on JavaScript, need to hold the user and then redirect.
+
+...: Are paths towards integration. Perhaps security key instead of TPM.
+
+Gerhard: We used webcrypto for a similar thing. Create private key and then do operations. 
+
+Kristian: TPMs are super slow and serial. So if you close your computer and come back 10m later, you might send 100 requests, and the server might believe they all need to be challenged. TPM can't handle that. Better to handle it in one challenge while the browser holds requests.
+
+...: Also, inaccurate earlier: for us in the consumer case, if there's malware, it could be in Chrome. We can't protect against that. Can protect against subsequent malware assuming the TPM is protected?
+
+Aleksandr: TPMs are slow. Not usable for this scenario. We'll need to iterate on other mechanisms. 500ms is P50. Don't want to talk about P95. MS' approach prevents malware even if in the website. Malware can't refresh the token for keys that don't belong to the device. Still, same goals. Need to sync up to discuss how to protect these sites. But different security promises between proposals.
+
+...: Attestation burner will be between web browser and IDP. Few hundred IDPs in the world. And those can do extra work to protect key if desired. But the rest of the folks can check whether cookies are present and the cookie has a key. Work is between IDP and web browser, not between website and web browser.
+
+...: I prefer headers vs JavaScript because of complexity.
+
+Kristian: Prototype we have uses headers.
+
+Arnar: If there's no JS and this is all headers, is W3C the right place for it?
+
+Mike: Less worried about venue at the moment, more about getting the right folks in the room.
+
+Kristian: Based on cookies at the moment, but could be anything, really.
+
+Arnar: Session setup is separeate from cookies. Just happen to use them for the short-term credential
+
+Feedback: On GitHub for DBSC. Same for BPoP <aka.ms/bpop>.
+
+### Source Code Transparency
+
+Daniel: Proposal to log source code, similar to CT. Presented at TPAC. Still very rough, but produced an explainer doc: <https://github.com/twiss/source-code-transparency/blob/main/explainer.md>. WICG proposal: support would be welcome! <https://github.com/WICG/proposals/issues/124>