WEBSEC WG Tuesday 1300-1500 Chair: Tobias Gondrom Minutes taken by Paul Hoffman; did not repeat things that are on the slides Administrativia, Blue sheets was done WG Status, draft status - Tobias - 10 Min Two drafts presented in Maastricht MIME Sniffing Web Origin Concept Will both be published soon These might be in WG Last Call soon Not yet in the WG draft-masinter-info, may conflict with MIME sniffing X-FRAME-OPTIONS Running code in MS and Chrome draft-hodges-strict-transport-sec Jeff Hodges Threat model Recent news: Firesheep Talk TLS to me regardless to the links returned in web content Policy scope maps to all ports Peter St. Andre: what if there are two conflicting policies at different levels? Jeff: needs to be addressed in the spec Also implemented natively in Firefox 4 and Google Chrome 4 LockCA Certs must be issued by the same CA as when first seen Richard Barnes: Maybe generalize to other parts of the certs EVonly Must get next cert from a CA who does EV Ekr: I don't think this really what we want at all There are methods for doing this, will take it to the list Paypal thinks this is a small step and better than nothing Wants exclusion for keys and certs HTTPbis might be done in early 2011 Tobias: How many have read? 10ish How many have posted comments? 0ish DNSSEC for strict security Paul Hoffman discussion of potential relationship with HSTS and implications of both work together semantics of DNSSEC strict security and HSTS DNSSEC strict security is not limited to HTTP but can also apply to other protocols avoids "trust on first usage"-issues as you get info from DNS before first usage offering different mechanism to receive security information via DNS and hsts(via http) can be advantage comments: to be considered: careful discussion of assumed security properties of signed data in DNS is advised comment from Pete: no clear what the second mechanism gains you from having both to counter man-in-the-middle, answers from Paul, Jeff, et al: - not both man-in-the middle need necessarily have both capabilities to disrupt both mechanisms, - benefit can be that HSTS gains you the ability to deploy right now which gives value and both - can work together and both should be done to avoid conflicts of semantics of both mechanisms, both should use the same semantics coordinate the drafts and get the semantics right DNSSEC for strict security Phillip (Tobias on behalf of) Will discuss the proposals and decide around the next meeting Requirements - Jeff - 15 minutes Content isn't a good term: maybe "mobile code" is better A buch of this stuff will be done in the W3C Maybe can do some of this with host-meta, which is nearing completion Who might want to review: Paul Barry Richard Leif Hannes Who is willing to write: Jeff Phill Richard Paul Hoffman: Doesn't like policy moving down Richard Barnes: Keep statement of fact separate from preferences Andrew Sullivan: Don't want to do that because DNS weenies will come with pitchforks Tobias: What is it we are trying to solve? Look at what OWASP is doing Can we solve existing problems Jeff: This doc is just requirements Framework that meets the requirements comes later Paul volunteered to do a trivial draft that has a new RRtype to hold the discussion