HTTPbis IETF85 Minutes ====================== Session I ========= WG status -------- no bashing Change overview --------------- -21 drafts are out and in LC overview of changes made in the latest draft (substantial only) no feedback on the changes that were made in the -21 drafts ACTION: mnot to create a ticket for https caching exception Security Properties ------------------- mnot raised the issue of security properties of http and the current status of the draft (draft-ietf-httpbis-security-properties-05) barry leiba: not sure that this has any correspondence to reality; if we adopted something better than basic then we would not need this (according to S Farrell); not sure what this really has to say mnot: it needs to more specific if it is to be useful, which limits its lifetime. This is a product of a bygone era, and we might not have the expertise to finish this sort of work, regardless of the merits of improving security as a goal bleiba: suggested that this be moved to the new authentication bof and resulting wg =JeffH: did this as a measure of charity; there might be people who can do this within this group; i may not have time to continue this myself bleiba: murray will do it roy fielding: we haven't added all the security considerations mnot: are there missing considerations for the broader web rf: there are http considerations, but those should be in http documents; if there is anything left, then we can look at that jh: there is a lot of good stuff that should be written down; but I haven't done the gap analysis eliot lear: I agree with the chair that you need implementor interest, no matter where the work is done. Is there that interest? mnot: there might be some stuff from here that belongs in drafts, but some is clearly out of scope el: please put it to bed bl: this predates our existing security considerations, which may be adequate now sean turner: this would be good to have and it is part of the charter bl: can you (st) read this and make a recommendation to the group? mnot: obviously web security has problems, but whatever we produce has to have some relevance st: you can force the issue by going to last call; or set a time limit for "put up or shut up" mnot: it's still pretty draft-y Other LC Documents ------------------ rf: last call comments thus far received should take only a short time to resolve rf: concerned about the lack of review in p5 mnot: jreschke is expecting to go to proposed standard and to move to full standard once we've gone through the http/2 process and discovered all the bugs mnot: can we go full standard? alexey melnikov: no active issues ------------- jr: (most of these arefrom Dan Winship's review of p1; I haven't entered those for p2 yet) ===395 rf: do we allow some leniency mnot: this could just be statements of fact rf: ok mnot: do we have other requirements around connection: close ? mnot: it could be prose ACTION: make SHOULD statements on Connection header handling prose instead of 2119 language ### 397 ACTION: put the exception for OPTIONS request to a proxy and the resulting URI ### 22 just tbd, no real issue ### 350 mnot: we can close this one ### mnot's WGLC p1 review rf: asks for fresh eyes over the drafts mnot: asks about what is specific to HTTP as opposed to HTTP/1.1; what can we do to improve the way that this could be made reusable for HTTP/2 no conclusion #### What are the parsing requirements for obs-fold with respect to the MUST? rf: if you can find no interoperable folding implementations, then we can remove it from the grammar [[scribe: may not have got this right, action more important to capture]] ACTION: mnot to run some tests on folding to understand its interoperability #### shared caching on https rf: the statement in question only applies to agent-side intermediaries and user agents, not to content accelerators, which are part of the origin server rf: some user agents use a common interface to make the request, then have separate logic to decide how that information is made available to other users rf: to know whether it is safe to send to other servers, you have to know the content mnot: you can use Cache-Control ...some disagreement here roberto peon: there are transformative intermediaries; we don't need to specify this mnot: need to know who this applies to rf: this applies to libraries in clients mnot: segregation... a shared cache can even apply to the same box martin t: 'never "public"' contradicts what has been said about caching rules paul leach: override Patrick McManus: on a phone, different apps can share the same network context ACTION: follow up on this issue ### on US-ASCII or a superset of it mnot: moving on ### on whitespace between start-line and headers rf: I thought there was some guidance on this mnot: we should find that text rf: S19 should not have had any normative requirements in it mnot: we can remove this then mnot: think about consolidating the list construction rules that are specifically called out for Transfer-Coding rf: this defines the framing and more explicit rules were asked for mnot: ok ### for render as complete or consider as complete kevin falk: are you prohibited from using particular code blocks to users? rf: the important consideration is that the user is able to learn that the information is incomplete julian r: that is getting ignored in practice brian smith: we (Mozilla) ignore this requirement, pages are already displayed mnot: would it be OK to show status in the web console? rf: not really bs: there are UX considerations that make this more difficult than it would appear bs: there's not much difference between XHR and the render as HTTP clients jr: we could add an indicator ted hardie: visual indicators are not necessarily universally applicable rpeon: there is a lot of confusion stemming from this statement, prefer the parenthetical bsmith: no idea about how XHR works, though it does have streaming modes; script developers are important will chan: chrome ux people didn't like the idea of having something in chrome rf: this is a safety/security feature kfalk: incomplete !== error julian: there is a related issue about truncated *downloads* (as in "save as"); Eric Lawrence once blogged about it () pmcm: rathole, we (Moz) do very little prescribed error handling and it's strange spending time on this when there are many others; tried to rollback rendering when MD5 sum failed, got immense push back mnot: maybe this should be prose ACTION: Roy to make this prose text in the security considerations #### whitespace tolerance in headers and the requirement to product a 400 when the message doesn't match the grammar #### no enumeration for the hop-by-hop headers that are not required to be added to Connection header. rf: this will be forwarded if they aren't in the connection header; having a list would cause problems with intermediaries that pass these mnot: this could surprise some people and should be called out rf: this should be noted as a change from 2616 jr: we already have this mnot: we probably need a callout for this one rf: I'm trying to reduce the number of occurences of this; they don't help the people reading the document for the first time Server Ranges ------------- mnot: this doesn't really mess with semantics, it only messes with intermediaries to the extent that range requests are hard to do anyhow mnot: streaming and ranges require the complete size to be known, changing the length would not be possible kfall: that is not part of the proposal pleach: does this work with unmodified implementations? kfall: not known pleach: profile... mtho: prefer might help to signal (all/some) mnot/kfall: makes sense bsmith: if the server provided less, would we be able to render it? the spec seems arranged around the idea of a "complete message", this might need to be re-addressed mnot: disagree, this should be addressed and if you can find something that isn't, please bring it up rf: yes kfall: what now? rf: how much testing have you done with clients that expected the bits that they requested? kfall: that's in part why we asked rf: testing first might determine how to proceed with this, if this kills an existing client, then this is a no-go mnot: 206 is close enough mnot: mumble, mumble, vary... rf: vary isn't so relevant in this case, it's for selecting representations mnot: fine ACTION: kfall to review -p5 draft-fielding-http-key-01 -------------------------- A not-dumb Vary header roy outlines the idea that you can make a request without headers to avoid the fingerprinting thing, detect the variances that might occur, then make more requests cyrus daboo: key == too generic roy: I don't care if its confusing, and number of bytes on the wire jr: application/*+json, globbing conneg roy: no, breaks stuff Session II ========== ticket #385: upgrade mechanism ------------------------------ ### TLS Upgrade for HTTPS URIs See thread rooted here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html mnot will send the message suggested in that above message to the tls chairs and show up in the TLS session this afternoon ### Upgrade for HTTP URIs Gabriel M. is going to present on upgrade-based negotiation for http/2.0 -- which is one approach to addressing the issues in the "http uris" section of the issues outlined in the mail msg roy at mike: don't need to prefix the header fields; they're just header fields mnot: it's side channel info, for optimizing roy: as soon as sent in http1.1 they're just a header field, register them, don't need prefix jhil: would those http2 things get stripped out? gabriel m (gm): yes mic: have any tests been run to confirm viability in the wild? as presented before, data shows port 80 has trouble with non-http1.1 protocols. or do we just want to ignore that? mnot to mike belshe (mb) -- we're getting there gm @mic: phb@mic: 1st thing is successful upgrade, 2nd thing is what to do if it fails jhil: is there a timing issue with expect 100 continue ? mnot: do an upgrade and combine with expectation? roy: wouldn't normally do that. the 1st request you make shouldn't be a large state changing operation roy: so you send options or GET first (so it's not a packet loss issue) jhil: so perhaps need note about that in spec mnot: discussion we need to have is whether a upgrade like this is workable for us -- in hybi they figured that about 70% conns using this would be successful, rest would fail fielding: you don't upgrade a request while sending a large body and Expect 100-continue -- it is simply not a use case that is relevant. It might work quite well, but it simply isn't worth being concerned about. mnot: so perhaps deploying using this it'd encourage the internet to upgrade, but only if we have fast failure fallback patrick mcmanus (pm) @mic : in FF, doing 6455 (?) the TLS success rates are substantially better than the plain success rates. Roughly 80% with TLS, maybe almost 70% with plain HTTP mic: what did success mean in this case? salvatore@mic: its true we had not so good success rate with plain upgrade, but lots of boxes will be upgraded, and they (?) just relaeased boxes with spdy support and [we'll see what happens (?)] mnot: there'll be several versions of the protocol out there because we're going to try various approaches mnot: the upgrade mech needs certain capabilities, eg supporting opportunistic use of TLS mnot: calling for data on how upgrades are working -- with data we have now, it seems if we design this thing well it';ll either succeed or fail fast ---- wondering about what folks thing whegther we should go down "this path" mic: should pursue this path, but need more data. pm: let's talk about the other approaches mnot: ok, another approach is "Using a SRV (or other DNS) record" (from mnot: have heard that there is general interest in using DNS as a mech, and do folks think we shouldn't use SRV? Mic: NOT in favor of SRV. ekr: this is 1st time mention srv, realise that the TLS server id check you do is with name you started with, not with the one srv gives you mnot: yes jeffh: Mic: What are the goals? Please be specific!! mic: is there a serious proposal around srv? or is this at the brainstorm stage? mnot: we're at the brainstorm stage cyrus d (cd) @mic: i get http://example.com and running http/2 on that, but on example.com:88 running http/1 .... pm: if uri contains port, then we're not going to do the srv lookup (?) phb@mic: the dns is where u make assns re names; should bind names & prots "in dns"; there's practical issues with doing this; in how clients use dns; don't nec use srv; want to use dnssec; so going to use "new dns" world anyway; and so may want srv+ pm: this is more work everywhere, u can set this up; and so in one round trip get all info u need, can mux with this btwn http 1 & 2 and whatever, so this approach gives some nice benefits ? @mic: if u get a diff port from srv, do you use that? mnot: there's a lot sec related concerns here need to be careful eric nygren (en): having srv records would be an advantage; addtnl benefit is having sep servers handling http/1 and http/2 -- help deployment mnot: inclined to say this (srv/dns stuff) will be a work item for us mnot: upgrade mech should start in main draft ...3d mech " 2) Using a response header to hint that HTTP/2 is available on another port" from ted: there are still often many different http servers running on different ports of the same host roberto: Martin Thomson: Enumeration is: TLS nextproto, HTTP upgrade, srv or other DNS record, alternate-protocol header mnot: start developing DNS based, and a response header based mechanism as well. Selected editors for core HTTP work, Martin Thompson, Aleksy Melnikov, and Julian Resshke will be helping out Eliot Lear: I volunteer to develop at least one DNS-based proposal mnot: don't want to put all work on them header compression ------------------ Herve Ruellan slides on HTTP Header Encoding Results http://www.ietf.org/proceedings/85/slides/slides-85-httpbis-1.pdf jhil: think about impact on mobile devices such as power required ? agl @mic: so now spdy compression has issues with trying to avoid crime attack rp: but its still useful as baseline mnot: see github.com/http2/http_samples - this is a corpus of header samples; har files from pcap captures. cd: what about webdav et al? mnot: if you want to submit traces for that, please do jhil: prob need some enterprise traces because of strange cross-domain cookies we see, but need to anon them mnot: ... but not concerned about pathological cases jhil: but might help show which compress scheme is better mnot: next thing come up with script that analyses this stuff, and eg can emit a pathological case, and then run compression algs on it and see how it works rp: can do this in python & work with mnot roy: http2 is not a minor hack -- need to do it carefully -- perhaps we should have better encoding for header fields, eg cookies are huge, this could be binary, if we define an encoding, then can encode cookies when sending over http and get diff comp results mnot: we can define new headers that have diff encodings eg binary, and then downgrade them to eg txt when sending over http/1 roy: a cook header field, obviously can't change that due to existing browsers, but browsers just store it and replay it; new thing doesn't have to be compat with existing cookies, so if svr has choice to send short cook rather than long one.... mnot: two diff things here, one is http1 <-- > http/2 <--> http/1 w/o loss; the other is doing stuff in http/2 that are new ( and then needing to downgrade new stuff into http/1 as nec ) mnot: if u can compress a bunch of requests down to fit in one underlying pkt, then that's very powerful, esp in mobile world; inclined to keep that in mind when selecting compression approach; .need to keep memory & cpu & power overheads in mind rp @mic: web app developers shouldn't have to opt their site to "make it fast" -- rather should make protocol fast mnot: yes phb: what about patent issues in compression? mnot: they'll have to disclose phb: if u make disclosure call now it has implications down the road mnot: we'll deal with that later mnot: we prob won't choose perfect comp mech for all time, thus negotiate comp mech? mnot: if upgrade mech is adequate, then can include comp mech in that, but if too much optionality there, that's interop probs mnot: would be nice if can put it into debug mode to see stuff on wire -- so question to be able to turn comp on/off ?; .thoughts on this? rp: perhaps can put stuff in there to make debugging "easy" rather than "turn it off" mnot: roberto wants to talk about http/w compression http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-00 roy: yes, the compression ratio gets better if you send garbage on the wire roy: notes that a fixed id space is essentially a registry in machine readable form rp: yes; but its not a reg that needs to be maintained after its created martin thompson (mt): dont understand where huffman encoding comes into play? rp: draft needs work; what is huffman coded is the text in the headers. ran analysis over sample of headers, and then used that to gen id space seems to me that we are maybe doing this the wrong way rp: hopefully impl code for this is better to understand than the I-D at this point :) mnot: so we know sorta where we going on compression stuff, want to get impls plugged into the http2 namespace on github -- the more visible we can make this the better the question was: do you have a note well on the repo #387: server push ----------------- We need more data / experience. Other Issues ------------ ### Flow Control gabriel montenegro (gm) -- flow control principles for http 2 hildjj: we need TSV help for this part. roy: init exchange over tcp, client begins; with this do you expect server to send anything first wrt state? gm: in spdy there's default 64k per stream rp: basically need default for safety reasons, but a better FC mech than spdy3 exists, hopefully will be proposed, can make larger than 64k by defualt ted hardie(th): what impact if doing multipath tcp under this? gm: yes need to figure out interaction with newish tcp stuff under it mnot: is FC tightly bound to what xport's properties are? gm: yes rp: jhil: we need early involvement by transport folks, don't wanna make buffer bloat worse rp: don't think that's possible will chan (wc): would hope that FC in http/2 doesn't subvert xport FC; want to make sure we saturate link; this should be one of the principles gm: thinks link saturation depends on how the work; don't have to solve now alison mankin (am): if receiver has FC turned off by intermediary, that messes stuff up. gm: but receiver controls it for his hop. is concerned about middleboxes at http layer; at that layer the proxy has to heed what endpoint (receiver) wishes. still concerned on traps that may be there rp: there's finite buffering available for entire path length; if receiver says stop, it'll stop eventually; but as soon as an intermediate is in the path, they have influence on FC gm: we need to codify the rules in the base spec mnot: gm will have draft coming out, please review. FC will get a new issue # ### Priorities pm: priorities need discussion mnot: will create issue for that (framing, diff frame sizes) rp: want to agree and disagree wrt priortzn stuff -- need more experimentation mnot: sure, may defer disc of these issues, but want to get em written down ### Mapping to TCP eric nygren (en): mapping to tcp -- need to disc mnot: yes, need optional draft on "how i use tcp" rp: agree with en that'll be issue, might wanna address earlier, need to get sec folk thinking about that en: also has implications for prototcol upgrade mech, signalling may make this easier or harder ### Framing gm: did u raise issue on framing itself? mnot: it will get raised; specific concern; useful for e.g., sendfile() Wrapup ------ mnot: am gratified to see folks working on drafts; continue doing that; will use wiki to record current state of proposals; interlink to issue #s; will also use github; will hand out access to (sub) repositories; the actual drafts will be in ietf subversion service; mnot: f2f meetings are effective for work like this, involves lots of folks, need to confirm decisions on list, tho possiblities of interim meetings, may be good idea here in earlier phase like this, current plan is interim mtg in Jan 2013, 2..3 days, offer from Ian Fette to host in Tokyo, need to get dates, maybe mid Jan to early Feb, pls send dates ideas to mnot mnot: any more biz ? phb: discussing compression -- was of msgs, not conversations -- in mobile -- sending "pages" with lists of links --- but maybe do html-conscious compression ? jhil: don't we get some of that with svr push? en: if start with http1, include an encoded blob of handshake framing? mnot: that's in category of cool tricks we could play. mnot: keep drafts coming, will send minutes out soon, if hold this interim mtg, want to make it useful adjourned