======================================== IETF httpstate WG DRAFT Minutes for IETF-78 Maastricht, NL ---------------------------------------- Monday 1740-1940 Afternoon Session III ======================================== Chair: Jeff Hodges Minute Taker: Paul Hoffman agenda: http://www.ietf.org/proceedings/78/agenda/httpstate.txt audiostream: http://www.ietf.org/audio/ietf78/ietf78-ch2-mon-afnoon.mp3 httpstate session begins at about 2:31:30 into the stream/file. 1. Agenda bash & Blue sheets No bashing 2. Review changes from -08 (LCWD) to -09 Presented by Adam Barth spec: http://tools.ietf.org/html/draft-ietf-httpstate-cookie Gave long list of small changes on main slide Julian Reschke: Don't worry about the URL for the original cookie spec You'll have to deal with the RFC Editor anyway Adam: Can it be hosted on an IETF web site? Paul Hoffman: No, still no policy for this Special processing of date header -- Only vendor doing this is Firefox Adam: will register a bug on this with Mozilla Will put out a -10 right after the meeting ends (done) 3. Discuss changes yet to be finished (if any) Julian: Wants more ability to read as a stand-alone document Adam: Names for algorithms vs. parameters passed to algorithms Julian: maybe make an appendix to describe these hooks Julian: Inconsistent that some requirements are in ABNF and some is in code The current doc is hard to understand for people Intro to algorithms could describe the difference between strict vs. non-strict Adam: risk of restating is that people who only read one part might get it wrong Mark Nottingham: clearly state that the algorithm is mandatory but also include parts Julian: is sad that you have to run the algorithm in your head in order to understand what the actual cookie header looks like Adam: maybe add introductory text to each algorithm saying what it will do Jeff Hodges: wants section 5 to explicitly say that it can parse anything that comes in Peter St.Andres: any sort of garbage come in so describe what to do with it Adam: interesting that this is odd for this world, this is the part that tells you what to do JeffH: (queries room) do we need to do another WG last call Room's Answer: no 4. Discuss possible future work post-httpstate-cookie "Public suffix" http://tools.ietf.org/html/draft-pettersen-subtld-structure-06 Yngve Pettersen Possibly want to create a black list to help the ".co.uk" problem with cookies Possibly make the rule that a cookie can only be for the host or a subzone Possible denial of service from malicious cookies Peter: maybe get rid of theory of "subdomain" Yngve: but people have deployed servers this way Martin Thompson: Had a discussion in HTTPbis of resources that don't have a domain in them... What would you do with that? Adam: already covered here because you don't have to do HTTP Adam: it would be better if each domain had a separate cookie store Maybe sites that want to have many coordinated hosts should just do it on their own Knows how to restrict but doesn't know how to make federation easier Paul: DNSext people really object to this approach because it smudges administrative zones, and they've worked really hard to get that stuff right. thinking about perhaps not calling them subdomains in the context of an admin zone might be the thing to think about or work on. Yngve: but that does not reflect how the net currently works in deployment, public suffix lists are out there and are being used by browsers Adam: this is not good for forward-looking work, in terms of being based on the way things are done now, due to deployment difficulties -- we should look towards doing different things Peter: A useful contribution might be to craft an informational document on what people are doing today wrt subdomain/TLD handling... "Securing HTTP State Management Information" http://tools.ietf.org/html/draft-salgueiro-secure-state-management [ Gonzalo Salgueiro wasn't present ] Adam: if you can see someone's cookie you can forward their state to somewhere else This adds some encryption to prevent that Mark: is this signing? Adam: roughly, yes "CAKE" (aka "Simple HTTP State Management") http://www.ietf.org/mail-archive/web/http-state/current/msg00893.html Adam Barth A "thought experiment" driven by pushing hard on the notion of simplicity. Every origin (host+scheme+port) has a nonce When client makes a request, it asks the nonce Goal: maintain state between client and server Main problem: integrity -- Even if a site is on HTTPS, network attackers can overwrite your state, by cookies sent over HTTP JeffH: strict transport security is trying to mitigate this In Gmail: an attacker attaches his cookie to another message This is about clobbering in the cookie store, not in transit Mark: there is some work being discussed in terms of generic HTTP header signing in the headers Adam: need a way to segregate state between HTTP and HTTPs Mark: yes, and also need to segregate between tabs Mark: wrt Cake, is the goal to replace or supplement current cookies? Adam: replace, in the use case we are most interested in: secure sessions management. Otherwise cookies are useful for other use cases. Most sites use nonces for session identifiers already. JeffH: in general, we need to think about HTTP state management overall, not just cookies, hence CAKE is interesting Martin: the nice characteristic of cookies is that they are really flexible. Maybe just add a few restrictions. reduce scope to an origin. Adam: it's common to use HTTP for everything but use TLS for getting passwords, thus need some way to communicate state between the TLS-based part of site and the plain HTTP part. Martin: just use redirects, like OAUTH Adam: that is not secure, can get the user's data placed into an attackers' context Mark: maybe make cookies read-only on HTTP and write-only or read-write on HTTPS. Different way to do what we want is is TLS client certs. Maybe have the client generate a self-signed certificate for a limited period of time Can pregenerate the certs; they are not server-specific Yngve: proposed alternate idea, will send it to Adam Carrasco: asked for more examples Adam: send public key in HTTP, then use it in HTTPS Has advantage of reducing number of cookies Mark: will talk more about signing HTTP headers a la DKIM, maybe with these ephemeral certs. Mostly interested in response signing, but some in request signing Cyrus Daboo: ischedule does DKIM-like signing of headers Needs to be dynamic Yngve: can agree to a key and just MAC Adam: might not work that well in federation Jeff: this interacts with HASMAT Can prevent this being used over non-secure transport Peter: there seems to be some energy in doing this More than just state management Ekr: thinks it is non-crazy idea Encourages to bring it to the TLS WG at the same time --- end