Minutes - XMPP (IETF 88 - Vancouver, BC, CA) - Friday 8 November 2013 0900-1100 [The chairs wish to thank Andrew Biggs for taking minutes.] Meeting materials available at http://www.ietf.org/proceedings/88/xmpp.html Summary: -- XMPP/WebSocket Lance led discussion on multiple open issues. We made progress on several issues, but further list discussion is needed. “see-other-uri” discussion needs to continue on the mailing list. We agreed in general to “one stanza per frame”, but we need to get some examples for alternative approaches and work out details. We need further discussion around authentication, channel binding, and TLS, and make sure we fully understand (and document) the implications of moving security decisions from the XMPP client to the browser. -- TLS in XMPP Peter presented draft-saintandre-xmpp-tls. The draft proposes updated and stronger rules for the use of TLS in XMPP. General agreement that this was useful and that work should continue. Several open issues on how to proceed need further discussion. -- 6122bis PRECIS completed WGLC on the framework. Chairs will coordinate with PRECIS on when/how to move 6122bis forward. We should consider whether this will eventually fold back into a future version of 6122. -- XMPP DNA Matt presented progress on XMPP domain name assertions. We need to determine how to move forward given the dependencies on posh and dane/dnssec. -- Open Discussion We had short discussions about end-to-end encryption/signing and whether dialback should get pulled back into the IETF standards track. Detailed minutes from Andrew Biggs follow: ----------------------------------------- XMPP WG Minutes =============== Presenter: Lance Stout, XMPP over WebSocket ------------------------------------------- Discussion of introducing "see-other-uri". * Questions posed on what it should mean, where to define it, whether it should be WebSocket specific or more general. * Matt Miller: sees value in doing it generic, possible use in BOSH and elsewhere. * Peter Saint-Andre: we already have "see-other-host", does a generic see-other-uri overlap with that? * Joe Hildebrand (floor): things could be added to "see-other-host" that include uri information. * Peter Saint-Andre: spec says see-other host requires an FQDN. * Jack Moffet: suggests we don't need the "see-other-uri", 3xx's should be sufficient. * Peter: poses question, when does "see-other-uri" get sent? * Lance: notes this would be sent just after stream is opened. * Matt: voices support for "see-other-uri", suspects we will need this. * Lance: poses question, would we use this to bump tcp sockets to BOSH? * Joe (floor): notes that use case isn't entirely clear, suspicion is we'll need it anyway but should be given more thought. * Rick Taylor: request for more context and explanation of proposal, why does common HTTP redirect not work? * Matt: "see-other-host" provides only host/port, "see-other-uri" can provide scheme, path, etc. * Matt: poses use case, user establishes connection, but server chooses to bump to another uri based on stream open information. * Joe (floor): notes m&m's use case is compelling.Being able to switch based on stream to-address is useful. * Joe (floor): notes we need to ensure stream cannot be downgraded from wss to ws, need to redo security context for new channel. * Rick: notes there is some conflation of discussion around switching protocols and switching security contexts. * Ben Campbell (chair): queries for sense of the room regarding resolution on "see-other-uri". introduces discussion on stream start/end, notes no streaming parsers in current browsers. proposes change to disalllow case of multiple stanzas per WebSocket message. , , are always in their own frames. * Martin Thompsen: poses question, should we consider each web socket frame a complete document? * Joe (chair): poses question, any concern in the room with one stanza per frame? No objections raised. * Joe (chair): will Nagleing algorithm be employed by browsers? (Martin, suggests the answer is no). * Joe (floor): concern with having a complete doc in each frame, naïve implementations may restart parser with each frame. * Martin: suggests performance is not likely an issue, small docs can be parsed quickly in browser environment. Acknowledgment that the additional namespacing may slow things down, though compression can address that. * Matt: with concurrence, parsers in the browsers are pretty efficient at this sort of thing. * Rick: with perspective from constrained environments, it's useful to not restrict options based on concerns re: naïve implementations. * Peter (relaying from Jabber, name?) - WebSockets doesn't define compression at the socket level. * Joe (chair): reflecting sense of the room: at most 1 stanza per message, each message parse-able as a doc minus XML decl., implies ns mixups. * Martin: suggests we need to be clear, implementers must be prepared to accept XML declaration, or must not include one. * Rick: poses question, if XML declarations are allowed on each message, is there going to be a rule re: changing encoding? * Joe (floor) - XMPP is always UTF-8. * Matt: points out the only processing instruction that is meaningful today is the prolog processing instruction, stream should fail if we don't get what is expected. * Martin: suggests processing instructions are largely ignored today. It's a bit of a burden to check them all each time. * Joe (floor): notes we need to also protect billion-laughs type attacks. * Peter (relaying for Jabber, name?) - server side impl. can just strip out framing and parsing above that. * Matt: doing the parse and serialize together is an effective means for early detection and protection against attacks. would rather we have to do it. * Martin: it is possible to do schema validation to protect against issues. * Matt: schema validation usually ends up failing due to extensibility model of XMPP, it degrades performance to the point of being unuseable. * Martin: suggests we don't process doc type, don't process prologue instructions, just let people just process doc directly. * Matt Miller: suggests this looks like a minor change, but need to ensure that this isn't going to imply a lot of new parsing work. * Joe (chair): queries, does anyone in the room feel they know enough to have a preference? * Joe (chair): suggests it would be good to see XML examples of the proposal so we can tell what we're choosing between. Discussion on Authentication, Channel Binding, TLS * Lance points out early consensus has been to use EXTERNAL if using authentication through HTTP headers/cookies. Does this still apply? Does EXTERNAL carry too many assumptions of client certs? * Matt Miller: point out this came up in kitten WG, many people thought EXTERNAL implies auth at TLS layer. * Joe (floor): we don't have impls that do this yet, servers should not send EXTERNAL unless semantics are clear. * Matt Miller: expresses concern with possible creating downgrade attack vector. * Chris Newman: we should use EXTERNAL unless client policy says otherwise (?). * Joe (floor) - sees a potential attack there, but client shouldn't start sending stanzas until it has verified the server. * Peter: it's up to the client to make sure it's talking to the right entity. * Matt: concern is the multi-tennant cases, may be authenticating against a front-end that doesn't match back-end (?). * Joe (chair) - lets take an action to look into this, take it to the list and think. * Martin: would be useful to look into rtcweb security and security architecture. * Lance: 6120 mandates SCAM-SHA-1 and -PLUS variant. Browsers don't expose channel binding information. EKR open to considering support if we present compelling use case. * Lance: the browser is in control of TLS, can't check for XMPP specific information. Implications for the XMPP TLS manifesto. How do we resolve this since we can't check it? * Peter: poses question, how do I know that the thing I'm connecting to, the XMPP server behind it, is what I think it is? How do I know that wss is the right one for the server I think I'm talking to. * Matt: security of the URI depends on trust of the origin from whence it comes. * Ben (chair): we need to capture this in the security considerations. * Peter: discussion on alternative discovery, .well-known approaches. question posed, do we think we're going to need/use this? * Lance: notes that he for one will be using alternative discovery. * Matt: proclaims, HTTPS is the new HTTP, and .well-known is the new DNS. Presenter: Peter Saint-Andre, TLS in XMPP ----------------------------------------- * XMPP history * 1999 SSL on separate port * 2000 dial back for s2s verification, but no crypto * 2004 (RFC-3920) STARTTLS on 5222 * 2011 (RFC6120) cipher MTI upgraded * XMPP present * most c2s are TLS-protected * many s2s connections are TLS-protected but few authenticated * lack of visibility into current state of deployment. * new IM observatory at xmpp.net * XMPP future * updated guidelines draft-saintandre-xmpp-tls * open "manifesto" to encrypt XMPP network broadly * test dates on early 2014, switchover to always-on channel encryption * also working on DANE/DNSSEC, POSH, key pinning, cert transparency * SSL/TLS version * SSLv2 must not * SSLv3 must not * TLS 1.0 should not * TLS 1.1 may * TLS 1.2 preferred * Cipher Suites * forbidden: NULL, RC4, anything less than 128 bits * preferred: forward secrecy, auth, 256+ security * Cipher Suites (list of recommended ciphers). * Software Configuration and Interfaces * servers and clients must provide options to require channel encryption, set acceptable TLS versions and cipher suites. * show admin or end user the encryption and auth status of connection. * TLS Usage * unauth conniptions are acceptable (opportunistic encryption, TLS+dialback) but string domain name assoc connection are preferred * TLS session resumption - use session IDs (RFC-5246), not session tickets (RFC-5077) * compression optional, since XMPP is not subject to CRIME attack, can use application layer compression * Open Issues / Next Steps * Is optimistic encryption really ok as a fallback? * Need to specify how TLS + Dialback works, Philipp Hancke volunteered to write a draft. * Consideration needed regarding multi-tennant environments. * Cite general TLS guidelines where possible, or make all-in-one document? * Will gain experience with TLS-only network in 2014. * Richard: separate opportunistic encryption from unauthenticated encryption. * Peter: Concurs with Richard, notes need guidance on the right terminology - doesn't seem to be a consensus on this today. * Richard (no hat): something 6125'ish could be useful here. May be a more general doc on how to do auth when there is no trust authority, how do you negotiate TLS in general in applications. Do you think a general doc like that would be workable or get to abstract? * Peter: 6125 started off seemingly simple, and it's not easy to do in a short timeframe. Longer term, a doc like that would be useful, to lay out the territory. * Joe (floor): talked about this in app area on Monday, seems there is value in laying out the choices you have to make in your protocol, and lay out some recommendations. This work, though, is worth continuing, at least as a precursor to such a document. * Peter: suggests starting from XMPP domain, get progress, then expand as appears useful. * Matt: may not get a lot done working on a very broad doc at the onset, that can actually make things more confusing. Presenter Peter Saint-Andre, 6122bis * Update on PRECIS wg, completed WGLC, need to update PRECIS scripts to test impact on future unicode changes on XMPP profiles. Presenter Matt Miller, XMPP DNA ------------------------------- * DNA, POSH, and DANE work moved to more general forum. * POSH BoF - held in Berlin, good feedback incorporated, detail the problem, two modes (pointers and keys), hash instead of chain, expiration hints. * Early POSH implementations - Prosody module, psyced, node-posh * DNSSEC/DANE - some advice incorporated into DANE WG, but expired. contacting WG chairs about steps forward * DNA - clearer intro, better order of ops, IANA registrations * Next steps - finish up POSH finish up DNSSEC/DANE, implementation and feedback. * Bernard - may be hard to get adoption by pushing both POSH and DNSSECv(?) * Matt Miller - adoption is slow, but we're improving it. * Dan York - Are you seeing a rise in implementation of DNSSEC? * Bernard - Within the US govt, there has been greater priority being put on this. * Dan York - so this is really is more in the US govt. than in the broader enterprise market? * Dan York - we're still seeing slow evolution of DNSSEC, google and comcast contributing, good push around this. New gTLDs all are coming out with DNSSEC signatures from the beginning. Also registrar agreement for ICANN is including this. In enterprise in particular, we're seeing some growth. * Matt Miller - we're pushing on POSH not because we think DNSSEC is crap, but because we need something *now*. Open Floor ---------- * Matt Miller - another draft under process: xmpp end-to-end encryption and signing. T This work depends on jose, it looks like jose is going to finish up core set of docs before London meeting. Some questions re: forward secrecy in e2e, but not clear that this is going to provide much in a protocol that strongly identifies you on either end. * Joe (chair): would be great to get more volunteers for the drafts. * Martin: disagree with assertion that forward secrecy isn't useful for e2e, agrees to assist with figuring out e2e and forward secrecy problem. * Peter: did some work to clean up dialback, moved to XEP-220, with Philipp. Now with DNSSEC. Poses question, would it make sense to pull dial backback in to the IETF as RFCs? * Ben (floor) - that would be nice to have in IETF if it's something that can be commonly used. * Peter: Now that we have DNSSEC, dialback is more sensible in an IETF draft. Good to get more eyes on it from IETF, something worth talking about. willing to put in cycles to do that.