IETF 87 Minutes of the WEBSEC WG Meeting Monday, July 29 -- 1510-1610 CEST 0. Agenda Bashing + Blue Sheets 1. Document Status - X-Frame-Options started its IETF LC as of July-29. - Framework-Reqs: no new version, one new message - HPKP gone through a WGLC, several issues raised, revised version. Mostly resolved in -08. 2. HPKP wrap-­‐up (Tobias Presenting on behalf of Chris and Ryan) A few open issues: Is SPKI the right thing to pin? Should we pin the raw public key instead. Should we allow pinning to a certificate vendor name? Tobias: on the mailing list there was support for keeping SPKI. Objections? Also, would be nice to have vendor name, but not much discussion Yoav: lists of trust anchors changes, also mergers and acquisitions change vendor name. Seems unwieldy. Tobias: any strong opinion about SPKI? Yoav: SPKI is used in certificate requests in other protocols. It's easy. Tobias: Any objections to SPKI? (silence) Tobias: How about provider name? Jeremy from Digicert: we like pinning the TA name because it's easy for customers. It is hard to maintain, but we can do it. PHB (via jabber): Pinning depends on Trust Anchor Management. If TA is revoked, it has to be tracked anyway, so I'm in favor of using names. Tobias: beyond two comments in favor no other comments in the room, so please post your comments to the list again so we can discuss and resolve the issue. Interaction with pre-loaded pins Tobias: We think current resolution reflects WG consensus. Yoav: there was a message to the list that said this was not clear. Never elaborated. Tobias: if you think what is in the draft is insufficient, say so now or soon Pin scope and cookie scope Tobias: potential attack scenario if scope of key pinning is not the same as scope of cookie. Tobias: proposed solution: accept the risk and explain it in security considerations Paul Hoffman: Question: If it's normative, it should not be in the security considerations. If it's just something you should think about, then Security considerations is fine. Tobias: agree. Question to WG: If you expect normative language? Please speak up now or send it to the mailing-list within the next 48hours. (silence) Tobias: so send to the ML soon. Well-known URI vs HTTP header Tobias: So far it has been in HTTP header. Got a suggestion to use a resource instead. Then someone suggested that the same could be done to HSTS. Con: need to get resource first and block. Jeff Hodges: This is one of the overall requirements for framework. I don't think we should modify HPKP just for itself, but only as part of a generalized thing. Not sure "well-known-URI" is the right thing to do. We should discuss this in requirements. Yoav: should do things the same way for now. But it doesn't have to be blocking. It's relevant for your next connection, so you can get it last or with low priority in HTTP/2. Mark Nottingham: Not saying to use "well-known-URI". I've been working on different kinds of infrastructure to make it easy to discover whether WK URIs exist, and in HTTP/2 it's cheaper. So if you want to go down this path, there's some work on the subject. Chris P (via Jabber): agrees with Jeff Tobias: So I'm hearing that it's potentially a nice idea, but not now. Some ambivalence, but mostly agreement with Jeff. Mark: Not sure if this is not just inertia. Jeff: don't do it for key pinning in this particular draft becoming an RFC. Mark Nottingham: Not about to shove it down your throat, but it has interesting properties JefF: in a general sense, I'd like to see what you (Mark) have been working on. Mark: Whatever you do now gets implemented, and never replaced. The framework is not going to happen, and a version 2 never happens. That's why this is an interesting little dance. Tobias: This is the discussion so far. Please post to the mailing list. Absent comments, we continue on the current path. Acceptable? Yoav: I'll send a message to the list asking for comments and saying that at this point, silence will be interpreted as agreement. Tobias: yes, we're done. Don't want to even ask if we should also move CSP, HSTS, etc. to a URI resource. Still waiting for update of draft to version 09, should be submitted within a week (as indicated by Chris). 3. Session Continuation Yoav: inspired by Mark during http authentication BOF in Atlanta. created a problem statement draft. Yaron Sheffer presenting on behalf of Nico Williams. Motivation: - e.g. protect against cookie based attacks. - manage the session and replay protection per message (more see slide 3 of the presentation) Requirements (slide 4) - whole list of requirements, the first two list are the most important: -- support for both unprotected and protected HTTP -- support for authenticated and unauthenticated sessions -- and reasonable way to move between states. Yaron: would like to ask WG whether the group wants to adopt this document - document didn't have enough enough discussion on the mailing-list yet, so probably we need more discussion before. Yoav: long list of requirements, is here the perfect the enemy of the good, could we remove some of them. comment(person unknown to scribe) - related discussion on the KITTEN WG a few years back, looking at negotiate for other mechanisms in light of Kerberos, there were a lot of expired drafts ("negotiate", ...) invite you to look at the previous discussions from KITTEN, possible useful to talk with Sam Hartman PHB (via jabber): context broken twice, citing BEAST and CRIME Lucy: - asks for clarification the sentence on state on the server. Do you keep server-side state management, e.g. keep a state in a DB Tobias (@Lucy): invite to post the question to the list Yoav: this issue keeps coming up again and again, in various mailing-lists and now in websec. Yoav: several solutions suggested on the mailing-list - channel bind cookies - session continuation protocol - https session management - CAKE (by Adam Barth) - smart cookies (on the mailing-list) Mark: - excitement: Mark has perceived a small group of really excited people, but not a large number of people. - we should get more folks from implementors and browser in the discussion to ensure adaptation. Jeff points out: note, Chrome is implementing/experimented with cookie improvements. Important to involve the browser vendors. Paul Hofmann: - problem: we want browser vendors interested. But browser vendors are probably more innterested in solutions and not so much in problem statement. (drawn from experience taken in IPSECME) - Shall we skip problem statement and just go directly to beauty contest of solutions. Tobias: - : propose to discuss different solutions and requirements in parallel, not wait for requirements Yaron: should use requirements draft to make sure we don't forget the more mondane requirements later in the process. Thomas: - chairs should ask: who in the room has access to a code base to do experiments, deploy and at scale, as informative question PHB: states, he has engineers and could do an experiment with 2 Mio user browser instances deployed. Tobias questions as WG chair: - who would be interested in willing to review the problem statement (show of hands, only 3 hands) - beauty contest, how many would be willing to review (hands: roughly a handful for reviews.) - do we have people who do have access to do such an experiment (PHB maybe...) - Mark: suggestion: browser vendors might not be willing to show hands in the room, suggestion to talk to browser vendors directly and/or operators of large sites Yoav: PHB has access to browser vendors in CA browser forum, could he help us? Paul: propose to browser vendors to try and implement their own (with lack of interoperability) and then go from there. We could see whether they have interest. - regarding CA browser forum: there are browser vendors in the CA browser vendors and there are browser vendors in the IETF. - suggest: we contact browser vendors, we want to hear from you either via document or code if you are interested. Tobias: - noted that before there were only a few hands raised for interest, is not a lot of interest in the draft at this moment. - propose: not to re-charter at this point to integrate this problem/draft into the WG charter. - propose: but to open the discussion on the problem and solutions on the mailing-list