Minutes - XMPP (IETF 89 - London, UK) - Tuesday 4 March 2014 1420-1550 [The chairs wish to thank Kevin Smith for taking notes.] Meeting materials available at http://www.ietf.org/proceedings/89/xmpp.html Summary: -- DNA/POSH/DANE-SRV The DNA framework has not significantly changed. DANE-SRV is being worked in DANE. Review requested. There's a general interest in POSH as an interim solution until DANE-SRV can see wider deployment. POSH may be of interest for other protocols. We'd like to see more implementor review. -- XMPP over WebSocket Most implementations have updated or in the process to update to handle the latest stream framing mechanism. We discussed whether we needed language around accepting redirects over non-secure connections. The sense of the room was that this was no more of a problem than trusting anything else from an non-secure connection, but was still worth calling out. Kevin Smith and Jonathan Lennox agreed to look at redirect language. There was discussion about whether the compromises due to the WS API created new security issues. The sense of the room is that they do not. -- IQ Handling Vulnerability We discussed the ID handling vulnerability discussed in draft-alkemade-xmpp-iq-validation. The room generally understood the issues, and hummed in favor of working on this problem. The chairs will confer with the ADs on adding the milestone. We did not address wether to adopt the draft in question. We expect to publish a fix quickly, then possibly role into a later "ter" draft whenever we work on one. -- End-to-End Crypto We've had little progress on draft-miller-xmpp-e2e due to the lack of input from people other than Matt. The group discussed whether we should just use OTR, continue with Matt's draft, or something else. The sense of the room was that OTR was not the right solution in the long run. The security ADs encouraged the work to continue, and will try to find help. Matt agreed to present a slide in SAAG to draw attention to the work. The chairs reinforced that XMPP was on a path to failure for this milestone, and that we needed a larger group to put effort into it. Detailed notes follow: ----------------------------------------- XMPP (IETF 89 - London, UK) -- Tuesday 4 March 2014 1420-1550 -- Status and Agenda Bashing -- 10 min (Chairs) -- POSH/DNA/DANE-SRV (Matt Miller) -- 30 min http://tools.ietf.org/html/draft-ietf-xmpp-posh-00 http://tools.ietf.org/html/draft-ietf-xmpp-dna-05 http://tools.ietf.org/html/draft-ietf-dane-srv-05 DNA framework not significantly changed. Updates based on dependency and author address changes. Recent feedback provided. Dane work in DANE working group. DANE SRV draft has more support for START-TLS. Please read whole draft. POSH now xmpp item. Only change is references. Depends on jose work. Expect them to go to last call in 2 weeks. [RB] Why do people want [standard JSON] comments? We don't know. No-one in the room can see why they're needed. JSON parsers widely available, maybe more so than for xml. JSON fairly approachable to people, easier for operators, etc. JSON? No-one puts forward arguments against. [JH]: Might be used for other protocols than xmpp. JSON more reasonable for larger audience. [KS] Can POSH use same comment approach as in xml streams for XMPP? That is, don't have them? [psa] Might be interest in POSH for email. [bc]: As long as we don't get wrapped around requirements from other communities we don't know, it should be general. [ks]: POSH requirement small compared to everything else one needs for an xmpp implementation. POSH is ugly but we need it. [psa]: People in HTTP community have same kind of issue. It would be nice to just use DANE, but that's not widely available. Need POSH in interim. [oj]: SIP is looking at similar things for caller-id fraud prevention. Next steps: Look for more feedback, implementers Three or four in the room commit to either having implemented or going to implement. At least one more once it's in the wild. Peter going to be chasing others. -- XMPP over WebSocket (Lance Stout) -- 20 min http://tools.ietf.org/html/draft-ietf-xmpp-websocket-00 Peter presents for Lance. (Peter is shepherd) Fair amount of offlist discussion about stream framing, so that things on a websocket would be well formed xmpp snippets Most implementations updated or in process of updating to use new framing mechanism. Need to be able to redirect someone somewhere else. Check that we should have text to say Do not accept redirects unless you're over a secure stream. [oj] Do you know you are talking to the right host when connecting over wss? (i.e. not proxy in between)? Browser does not tell you why if something fails. [jh] URI configured in by the person writing the JavaScript [rb]JS doing all xmpp logic is entity that provides the wss uri. Same failings as http. [chairs] This is going to turn into a problem for the TLS working group. We are not going to solve it here. [jl] Why should URI be less trusted than anything else you get over an insecure connection? [pse] understood, just be care. Getting JS from there. but shouldn't trust URL more than anythign else. [jh] Our servers only do TLS. [ks] Still worth calling out. Kevin Smith and Jonathan Lennox to check text for this after speaking at mic --- Process Interuption: Tea for Gonzalo --- XMPP: Texas Chile Chai SIMPLE: [something] Oolong --- Return to agenda --- How do you know what endpoint to go to. We have HTTPS well known, well defined endpoints. Could use that mechanism. XMPP/WebSocket tls at transport layer, not xmpp layer. Must not redirect to endpoint with lower security. Lots of discussions in Vancouver. Probably the best we can do given how WS works. Most implementations being updated. If you know of others, esp clients, please inform. [Chairs] Everyone understand changes, have process issues, etc, please speak up. [bc]: Whenever we think "this is as good as we can do with WS" we need to make sure it's good enough. Not picking on this specific issue. Is there anywhere we can push issues about the APIs,etc. [mm] W3C. APIs don't tell the application why something failed, just that it failed. [jh] Is that a bona-fide security problem, or just a deployment complication? [mm] deployment problem. Doesn't think there are any new security threats. -- IQ Handling Vulnerability (Thijs Alkemade) -- 15 min http://tools.ietf.org/html/draft-alkemade-xmpp-iq-validation-00 [ks]Re-using ids still has issues, outside of iq. This extends beyond streams, potentially. Easier just to say "don't reuse" [ta]: Don't reuse ids for which you are still waiting for replies [ks] Not a case of waiting for reply. You assume it will get through unless you get an error, which could happen some time later. [ks] Limit sometime between immediate and 5 years :-) Could conceivably be 10 minutes, or 4X tcp timeout. If you get an error, it would be better if it were unambiguous on which stanza it's for. [jl] Do we need to enforce froms at all if we have crypto-id? [ta] Complicated scenario exploit on MUC file transfer [jl] crypto-ids are a good idea. But do we need to prevent third party responses. [jh] only 3rd party response is useful server responding, have to trust server a lot anyway. [psa + ralph] Unique in stream is meaningless. Connection can go away, might get error on new stream. [ks] that doesn't mean unique in stream, that means unique in longer term, not short term. Crypto ID solves that but creates other problems. [jl] Don't need a lot of entropy--just a little entropy and a good prng. Crypto numbers would be effectively globally unique. [chair] Get some security people to make sure we are on right track. [matthew Wild]: Is it not just needed to be unique for a pair of jids? Not in favor of crypto unique IDs. [jh] Do they need to be unique, or also unguessable? [mw] only need to be unique if checking from address [ks] Can't forge from address unless you are server, in which case you don't need to. [ta] Linear (missed) RNG is really the same as using a counter. [ks] Crypto IDs would have solved problem, unguessable would have solved extra. Guessable IDs leak more info. [mw] Fine to use counter, if per recipient. [jh] Why does MW prefer not to be strong? [mw] Discussion on mailing list can be sidestepped if we allow but don't require strong uniqueness. Issues with entropy, not necessary to discuss what kind of randomness or types of algorithms. [jh] If wg decides we need crypto randomness, will ask for security expert inputs. Approx 20-30 people claim to thoroughly understand the problems. Many hums for, none against, the WG doing work in this area. [ralph] Nice to have this in core Joe as chair's intention is to get something out quickly, then roll into 3920ter, should we be chartered for such a thing. There will be normative updates to core. Please read draft and comment.. Chairs will huddle with AD on adding a milestone. -- End-to-End Protection Update (Matt Miller) -- 5 min http://tools.ietf.org/html/draft-miller-xmpp-e2e-06 (expired) We *must* read this and comment. We are bad people. Have not seen much energy in working group. Matt will not do this all on his own. [psa] Paul and Peter about half done with OTR documentation. Is OTR good enough for now? Miller draft? Something else? Nothing? [KM] as incoming sec AD: Wants to see xmpp e2e happen. Stephen Farrel has indicated he wants to see something e2e done. [rb] Stephen thinks nothing is not an option. [m&m] to do something we need energy to do it. [missed name] Have done W3C security for 14 years, co-chair of STRINT. OTR is more useable than any TLS he's ever seen. Kudos. Ultimate security is enemy of useable securty. Still has interface issues with otr as implemented right now. In STRINT, many people were pleased with OTR. Need to focus on annoying the spooks. [psa] OTR not created by xmpp. [psa] Need an informational RFC on OTR V3. Might could make a V4 someday that met extra xmpp requirements. [mw] OTR is not the right solution for xmpp. We would have to do something different to meet milestone. [jh] Agrees that OTR is not the right thing. [jh as chair]: Making Matt do all the work is not the right track. Currently, working group is on right track to make this work stop. If you want to do something, you will be on hook if we can't get consensus around Matt's draft. [Not nearly enough people have read this.] [jh] ADs will not let us declare failure. [jh] Anyone have a better approach? (no one speaks up) [psa] End users are okay with OTR. But it's not enough. OTR is not the right solution. Matt's is a good start, but we need people to help. [rb] May be under enthused pending on jose. Jose is moving now. Make one more try. [KM] would a comparison be helpful? -- Action for someone to compare the current approaches (particularly OTR vs Miller). -- Matt Miller and Kevin Smith volunteer to quickly document why OTR as-deployed is bad. -- Need to revisit the requirements document. -- Look for more volunteers to compare otr, miller, vs requirements. [chair] Who is willing to work on this? [A few hands, but not a lot] -- Kathleen to ask security folks for input. Will mention in SAAG, maybe perpass list. -- Take a slide to SAAG STRINT took action items to look at impact of metadata in xmpp. -- AoB and Open Discussion -- Any remaining time and energy