HTTPBis BOF minutes, taken by RL 'Bob' Morgan, slightly edited by Alexey Melnikov. ============= 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