[http-state] Draft httpstate minutes IETF-78 Maastricht

[=JeffH <[e-mail]>]

Please find updated draft httpstate minutes from IETF-78 Maastricht below.

I updated a few things in section 4 of the minutes below based on listening to 
the audio.

If you have comments on the below, please send them to the list (preferrably)
or to me asap -- the deadline for getting them into the IETF-78
proceedings is the day after tomorrow. I'd like to get them sent off by Fri 
morn pacific time.

thanks,

=JeffH


========================================
IETF httpstate WG
DRAFT Minutes for IETF-78  Maastricht, NL
----------------------------------------
Monday 1740-1940 Afternoon Session III
========================================

Chair: Jeff Hodges <[e-mail]>

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