Minutes - XMPP IETF 77 - Tuesday 23 March 2010 - Anaheim, CA, USA Summary: 3920bis: Work is almost done. A few minor issues resolved in discussion. No substantial major issues except i18n address related issues. draft-saintandre-xmpp-i18n: Internationalized identifiers are commonly in use in XMPP deployments. STRINGPREP is used by 3920. There is an open question how to move forward, as STRINGPREP is becoming obsolete. String prep issues are holding up publication of 3920bis. We need more research and discussion on how to move forward. 3921bis: DNA: XMPP hosting services need to prove permission to act on behalf of hosted domains. Current draft explores the use of attribute certs, xml delegation, and dns delegation. Author to produce a version 01 based on the feedback from version 00. 3923bis: RFC 3923 had issues that presented deployment, 3923bis intends to improve these. There are open issues related to certificate exchange, object size limits, and broadcast issues. [Note from the chairs: This was not explicitly discussed, the author is to produce a new version that addresses the open issues] draft-sato-xmpp-software-message-01: The author described issues encountered by applications that use XMPP for a transport, focusing on congestion caused by message loops and explosion. The author requested feedback, and possible co-authors. Detailed notes follow: -------------------------------------------------- XMPP WG meeting IETF 77 Administrivia - blue sheets - new chair (Ben replacing Sean) - note well - xmpp:xmpp@jabber.ietf.org Agenda Bashing - no bashing Work Items - 3920bis update (Peter Saint-Andre) * draft now at 05 (03 in hiroshima) * i18n addresses still the biggest issue * namespace-well-formed will be changed to MUST * stream negotiation changes * close long s2s connections of cert expires * periodic rechecking of OCSP responder * require re-authorization if cert changes materially * ekr noted that these security changes are difficult, and "materially" should mean "at all" * new draft (tls-server-id-check) for cert validation in arbitrary protocols * clarifications needed on SASL for the "simple username" * kurt zeilenga says JIDs should be unrelated to the security credentials, and to take out the defaulting currently proposed. Peter does not object. * mutual s2s auth: should one bi-directional stream be enough? * Joe Hildebrand noted that DNA has signaling that can make this doable in a backwards compatible manner - newprep (Peter Saint-Andre) * XMPP currently uses stringprep, but what to do now? * Peter's analysis of his own, large buddy list showed several i18n usernames and more than a few i18n resources * users like the ability to have non-ASCII identifiers, but deployments don't appreciate it * can potentially upgrade to IDNA2008 from IDNA2003 * if the prepping changes, this could lead to security and availability issues with services that rely on whitelisted JIDs * Peter described goals of localpart prepping * New prepping question: allow "name-like" characters; disallow other symbols; NFC vs. NFKC for normalization; harmonize with EAI and SASLprep * Bernard Aboba worries that this will block 3920bis indefinitely * Joe Hilebrand responds that this is the motivation for NewPrep BOF, and this is the correct discussion to have * Kurt Zeilenga notes that i18n DNS works because of aliasing, and wonders if server-side aliasing in XMPP servers is enough here. * Peter notes that resources aren't case sensitive and have other differences. Is this a good idea? * there are a bunch of migration concerns with a prepping transition * Who and when should a prepping policy be enforced? This is currently unspecified. * Prepping issues are currently holding up submission of 3920bis to IESG. * We need to do a little bit of research to see how big of an issue some of this really is. - 3921bis (Peter Saint-Andre) * version is at 05 (from 02) * presence probe changes: now OK to probe full JID; server can now answer probes based on outbound directed presence; responses to probes to full JIDs only includes information about that particular resource * There are some concerns about what to return to a probe for an offline user as this has bandwidth concerns. * Presence probes with 'id' attribute should be used correctly. * Change presence priority handling to allow server to override the setting. DNA (Stephen Farrell) Three options discussed so far: Attribute Certs XML delegation DNS delegation Plan is to produce a -01 documenting (some of) the approaches based on feedback Attibute Cert (AC) Approach Based on X.509 AC (RFC 5755) Hosted domain owner issues AC Pro: security properties are well understood Con: no library support XML Delegation Approach Pro: simple Con: security unclear, revocation, etc. DNS Delegation Approach Name hosting provider in DNS Proposal: _xmpp-delegate._tcp._im.example.com Pro: simple Con: dependency on DNS security Other ideas... - limited use certificate via EKU - query third-party services (e.g., xmpp.net) Eric Rescorla - DNSSEC is a nonstarter - and it is not okay to do it without DNSSEC - AC is "just a coding issues" Kurt Zeilenga - I think there are use cases other than hosting - all of these proposals are doing some sort of certificate authentication - if want simple, do DNS - otherwise, do ACs Bernard Aboba - there are lots of tradeoffs here - would be helpful to have a set of requirements Richard Barnes - I don't think DNSSEC is a non-starter Stephen Farrell - dodocument AC and DNS approaches? Eric Rescorla - I think also good to document the EKU approach requiring a webserver (for https) is problematic in some environments ... JH - people want their domain names - making people choose an ugly one is not a reasonable solution 3923bis (Matt Miller) 3923 had issues that prevented implementation (can we just the slides in?) :P we can open issues - key exchange (currently outside of the spec, needs to be worked out) - object data size limitations - broadcast issues ps - we punted on multiuser chat (XEP-45) problem - it's a hard problem Jack Moffitt: - how does this differ from OTR? [OTR protects only the plaintext message body] Joe and Peter confirmed that customers need more than , for example for file transfers. Also OTR does not protect XHTML-IM content (in a standardized way). It protects XHTML-IM, sort-of (but in a bad way). The client is responsible for feeding "the message" to OTR (which for Pidgin and Adium, includes markup). The "encrypted message" (base64 gook) is then sent in the . This leads to interoperability issues with clients not grokking markup when decoding. Next presentation... Hirotaka Sato (draft-sato-xmpp-software-message-01) * Several examples are given of various messaging loops involving single or multiple parties. * Possible solutions include TLL, path logging, back pressure Peter brought up that some similar extensions have been proposed, but there wasn't much interest in the community, such ashttp://xmpp.org/extensions/inbox/forwarding-delivery.html Joe Hildebrand has discussed backflow with a few interested parties. For example, calculating karma based on traffic *caused* instead of traffic directly produced. Cullen thanked with some lovely beans.