Draft minutes from HTTPBis BOF

Thanks to Ted Hardie for scribing in Jabber during the BOF and to RL 
'Bob' Morgan for taking notes.
Below are the notes produced by Bob, slightly edited by me.
Please send me any corrections before August 9th.
=============
call to order 9AM

introduction by Mark Nottingham:
httpbis:  why are we here
HTTP:  more uses, more add-ons, more user agents all the time
many issues with 2616, new developers are trying to second guess what is 
in the spec

Review of draft-lafon-2616bis by Yves Lafon.
two previous attempts to revise 2616
discussion on ietf-http-wg@w3.org list
start on 2616bis from new XML, with issues collected by Jim Gettys
24 issues closed, 47 active
comment:  closed only in sense of these drafts
  if official activity starts, all would be open again
  could be considered "design team" as input to WG
kinds of issues:
  references, whitespace, caching, security
comment:  errata doc has some official standing
question:  is the work described official W3C activity?
answer:  no official W3C activity exist at the moment
  the joint WG, way back when, used IETF process

Review of http authentication mechanisms by Robert Sayre, Mozilla
http://people.mozilla.com/~sayrer/2007/auth.html
security, resource control, affinity
almost all authentication in practice uses forms and cookies, why?
  site control over presentation, support for i18n, password control, 
logout, scalable
problems
  need HTML rendering, ad hoc credential format, credentials are just data
  XSS/CSRF vulnerable
  mixed security messages
2617 provides framework, but little used in comparison
Basic
  passwords in clear
  credentials must be sent in every request, no sessions
Digest
  does have session support?
  complex spec, only simple modes implemented
  dictionary attacks possible
  migration from old authentications databases can be tricky
  enables DoS attacks
various other schemes:  OpenID, etc
passwords are still passwords

HTTP and cookies, Yngve Petterson, Opera
cookie scope can be a problem in deeper domains
  site can set cookie which will be read by administratively distant 
server, possibly with bad effects
  various methods try to limit scope
    clients make guesses about relationship of DNS domains
  comment:  problem is that users want cookies to go to some other servers
    don't want them to go to some other servers
logout
  some sites want logout to destroy cache history
  no builtin behavior in clients, HTTP
session solution
  associate URLs with named context
    add other stuff to context, eg cookies, credentials
  server- or timeout-controlled expiration of context
  draft-petterson-* drafts on this

ETag on PUT issues, Cyrus Daboo, Apple

what does strong ETag returned on PUT mean?
clients don't know, so have to do a GET after a PUT to check
CalDAV and AtomPub have conflicting definitions
proposal:  draft-reschke-http-etag-on-write-07
question:  is it needed to specify one thing in 2616bis?
  or should different HTTP-based protocols go their own way?
question:  is it just that ETag is underspecified, needs replacement?
answer:  maybe
comments from chat room about differing interpretations of etag ontology

discussion of proposed WG

start with scope meta-discussion ...
proposed only to clarify, remove brokenness
  might lead to suggestions for improvements in future work
eliot:  concern that authentication improvement might need base changes
  so have to consider that when revising 2616, don't want to revise it 
twice
sam:  don't want to pressure new authentication work to fit 
clarification timing
lisa:  don't want this work to be individual effort
  has to be transparent process for large constituency, including 
consensus-assessment
  W3C doing usable-security work, depending on IETF for standard process
  to clarify:  indivual work is very desirable, but as input to process
paul hoffman:  have to make sure extensibility in RFC 2617 supports
  any required authentication changes
mark:  extensibility is actually good, but misunderstood, so it should 
be clarified
sam:  talk about specific authentication proposals
  current proposals live within existing extensibility
alexey:  so should 2617 revisions be in scope of WG?
cyrus:  propose 3 docs:  framework, Basic, Digest
  alexey:  we might chose to permit scope refinement, eg only framework 
in scope
robert sayer:  not much evidence of success with MTI authentication in IETF
  new mechanisms will take many years to deploy
  propose implementations of competing security proposals
    prior to writing docs
phb:  basic should be removed from 2617bis
  digest is obsolete, should be replaced with SAML/WS-*
jeff h:  support development of effective new authentication solution
sam:  digest is actually useful, don't ditch it, but don't spend lots of 
time revising it
  clarifications OK, framework doc OK
jeff h:  also look at non-use of 2817 (upgrade to TLS) as issue
phb:  password, reauthentication separable
  cookies not good enough for authentication state management

mark:  interest in having actual charter discussion?
  (most in room raise hands, perhaps 40)
mark:  include 2617?
eliot:  ask for at least weak dependency ordering
  eg, make 2616bis closing dependent on authentication clarification
michael richardson:  ask again why no TLS upgrade (RFC 2817) use in real 
world
jeff h:  can just keep authentication issues in mind, without solving in 
charter
chris newman:  keep authentication considerations in scope for 2616bis 
work, but don't put in strict dependency
paul h:  many modern IETF charters include "out of scope" sections
  as a response to scope creep
    but can lead to more confusion, people bet on future work
  so shouldn't have "no new features" in charter
alexey:  should discourage new features, not prohibit
michael richardson:  need to clarify "unwritten rules" too
  people care about progression on standards track
robert sayer:  if new authentication mechanisms are backward-compatible,
  shouldn't imply any dependency on 2616 changes, right?
lisa:  need something in charter stating authentication dependency?
eliot:  don't need it
bob morgan:  do need it, else won't affect WG practice
leif:  does authentication include layers like TLS?
sam:  yes
mark:  proposal on table is 2616bis doc
  and "security properties of HTTP" doc
    to satisfy MTI authn discussion
sam:  is second doc informational?
mark:  intention is BCP
paul hoffman:  strongly suggest authentication document not be BCP, just 
informational
mark:  show of hands, informational?
  (30 hands, none opposed)
chris newman:  need to get HTTP/SSL on standards track, not informational
mark:  in the charter?
chris newman:  sure (as participant)
alexey:  should https/2818bis work be in authentication WG due to 
channel bindings?
chris newman:  they're separable
ted hardie:  may have to modify 2817 also to fix 2818 (or 2617?)
john klensin:  have to clean this mess up! (he was AD who started the 
HTTP WG)
mark:  how many people think that authentication work should not happen 
in httpbis WG?
  (30 hands up; none opposed)
phb:  do need glue between http and authentication work though
leif:  as long as doing things with headers, can happen elsewhere
john klensin:  security work should be driven by app reality, not by 
security theory
  and guided by IESG, not at mike
lisa:  who would do revisions but not authentication?  (5 hands?)
  who would do authentication and not revisions?  (15 hands)
  who would do both?  (5 hands)
lisa:  hard to draw lines between different areas of work
  haven't yet seen the end of specific proposals, so hard to know
mark:  work on authentication is scary, may scare people away from WG
chris newman:  trying to move Digest forward on standards track would 
kill group
  focus on 2616 revisions, give some latitude, give chairs control
john klensin:  need a roadmap for the work prior to "creating a WG"
  and decision by relevant ADs on WGs after that
ted hardie:  are there volunteers for roadmap effort?
john klensin:  can't volunteer ...
ted hardie:  we're trying to avoid ratholes here, doing well
  having "requirements for extensibility" in charter is big rathole, so 
please remove it
mark:  larry masinter suggested those words ...
harald:  remove "security properties" item from this charter
  suggest moving concern about authentication elsewhere
lisa:  hands?  (10 agree, 5 disagree. Sam disagrees)
sam:  would really like to see the properties doc happen
lisa:  who can live with that item remaining?
sam:  can live with leaving sec properties out of charter
paul hoffman:  security properties sounds like a great individual doc
chris newman:  this item was my suggestion, would like to see it
lisa:  who would work (write/read) on the sec properties doc?
  (8 or so hands)
lisa:  work on cookies?  (5 hands)
  should be in charter?  (5 hands)
  not in charter?  (no hands?)
lisa:  see support on revising 2965 as in scope, but not blocking
mark:  everyone uses the Netscape doc, not 2965
harald:  is this consistent with no new features?
michael richardson:  yes, make what people are doing with cookies real RFC
alexey:  there is an alternative proposal that restructures 2616
  consider this as WG input?
kurt z:  does this matter to WG formation?
alexey:  some wanted to rule that approach out of scope
robert sayer:  that doc might compete well with the IETF doc, so it is 
better to have its proponents in the IETF WG
harald:  leave it to WG to decide
alexey:  incremental rev?  (8 hands)
  big rewrite?  (no hands)
  need to see proposal first?  (10 hands)
  so "need to see" seems to win
john klensin:  can't have "rewrite completely", "guaranteed no big 
changes" and "fast" at the same time
ted hardie:  agree
barry leiba:  leave change style to editor of document
alexey:  may have to decide between competing approaches
mark:  still open questions on 2617, 2965, sec properties
  so we'll take that to the list

Received on Wednesday, 1 August 2007 09:22:08 UTC