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

[=JeffH <[e-mail]>]

Please fine draft httpstate minutes from IETF-78 Maastricht below.

If you have comments on the below, please send them to the list (preferrably) 
or to me by Wed 25-Aug.  (the deadline for getting them into the IETF-78 
proceedings is the following Fri).

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


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:  DNS people really hate this because it smudges administrative zones

     Yngve: but it does not reflect [what?]

     Adam:  this is not good for forward-looking behavior
	
     Peter: A useful contribution might be to craft an informational
            document on what people are doing today


"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

     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 -- If user is on HTTPS, attackers can
                   overwrite your state

       JeffH: strict transport security is trying to mitigate this

       In Gmail: an attacker attaches its 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 between HTTP and HTTPs

       Mark: Also need to segregate between tabs


       Mark: is the goal to replace or supplement current cookies?

       Adam: replace, in the use care we are most interested in: secure
	      sessions Most sites use nonces for state management



     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.


     ?:      it's common to use HTTP for everything but use TLS for
             getting passwords

     Martin: just use redirects, like OAUTH
	
     Adam:    that is not secure, can get into the 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 for 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 HAZMAT
	       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