XMPP WG IETF 76, Hiroshima, Japan Wednesday, 11 November 2009, Afternoon Session 1: 1300-1500 Chairs: Joe Hildebrand Sean Turner Opening http://www.ietf.org/proceedings/09nov/agenda/xmpp.txt Agenda Bashing - It was agreed to reorganize the presentations to discuss the DNA draft first. - A presentation on XMPP Digital Signatures by Kurt Zeilenga was added to the end of the agenda. ================================================================================== Domain Name Assertions draft-hildebrand-dna-00.txt Joe Hildebrand presented the following slides: http://www.ietf.org/proceedings/09nov/slides/xmpp-5.pdf The purpose was to provide the motivation for the proposed server-to-server encryption solution. Problems with traditional X.509 identities if you delegate your hosting e.g., who holds private key? Current solution for server-to-server: No TLS, hope for the best. Also allows connection re-use between hosting providers -- 10k on each side => 200M sockets. If each end of the connection can provide multiple DNAs, re-use connection is possible. Resnick: Why isn't Alice signing another cert to give to Cho? Sean: Then Alice would have to have a CA cert, which costs more. Resnick: So it's a money thing, not a protocol thing. Peter: RFC 3920 specifies TSL+sasl-ext for server-to-server. Don't have a lot of deployment of secure conections with s2s... largely because of these scaling issue. Resnick: Certs can have multiple names in them, multiple signatures? Russ et al: Nope! Hildebrand: We also looked at multiple names, but that has operational issues. Regenerate cert every time you add/drop a customer. St Peter: some CAs also refuse to issue certs with many names. Bernard Aboba: You think you'll get deployment of a spec with ACs? Hildebrand: We have Google and Webex on board with this already. Sean: Pain threshold for AC is lower than TLS. Sean Turner presented the following slides: http://www.ietf.org/proceedings/09nov/slides/xmpp-3.pdf The purpose was to present the Attribute Certificate profile included in draft-hildebrand-dna-00.txt. It's based on RFC 3281bis; it proposes using: non-NUL subject names, OIDs to represent services/roles, AKI and IAN to point to AC issuer, no revocation, and signing with SHA-256. This proposal was briefed to the PKIX WG and there were no major objections. Text is still required to ensure that chaining is properly handled. New authors are solicited as the co-authors are the XMPP WG chairs. From the room: Russ: Don't you want the delegate's name there instead? Kurt via Resnick: AC is tied to a cert for the hosting provider. So if they get a new cert, they need to get all new ACs from their clients. Ben Campbell: Are you thinking about how to generalize? Hildebrand: Worth thinking about. Need to consider whether to start specific or generic. Peter: This is a pretty big pain point, but there are interesting deployment issues. Enough question marks that I wouldn't force it on other until some experience. HUM: Do you think that this work should be taken on by the XMPP WG? Few in favor, none against ================================================================================== Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence draft-ietf-xmpp-3920bis-03 Peter Saint Andre presented the following slides: http://www.ietf.org/proceedings/09nov/slides/xmpp-0.pdf Three revisions since IETF 75, upgrades to stream negotiation and security -- Several minor changes -- Added a layer of detail to stream negotiation Sean: How long are these connections open? Are you going to need re-negotiation? Peter: For server-to-server, weeks or months or like forever Sean: So maybe just specify for s2s, optional/MAY for c2s Peter: Possible, maybe do some experiments with open-source implementations -- Harmonized security terminology to RFC 4949 -- Added SCRAM as mandatory-to-implement (in add'n to TLS+SASL-plain and -external) -- Fixes some cert issues: RFC 5280 compliance, entity MUST NOT be a CA -- Does not seem that XMPP is vulnerable to TLS re-neg vulnerability -- Peers discard security context and perform restart after TLS (re-)neg -- Open issues: Optimizing re-connect? How to address internationalized addresses? Resnick: In a JID, do you ever see other than punycode? Hildebrand: Yes, absolutely. We keep them in UTF-8 Resnick: The domain piece of a JID is a domain, right? Hildebrand: Usually but not always. E.g., an internal conference server HELIOPOLIS: Are the domain portions of JIDs required to be valid u-labels? Hildebrand: Not exactly, need to be able to turn into IRIs Hildebrand: Problem is that stringprep stuff references unicode 3.2 directly => According to the spec, you can't use Cherokee ================================================================================== Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence draft-ietf-xmpp-3921bis-03 Peter Saint Andre presented the following slides: http://www.ietf.org/proceedings/09nov/slides/xmpp-1.pdf -- Changes to roster versioning and subscription handling -- Added version attribute 'ver' to roster so you don't download if it hasn't changed -- Opaque to client, may have meaning to server -- Differentiated from empty roster -- No known open issues right now ================================================================================== Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) draft-ietf-xmpp-e2e-requirements-00 Peter Saint Andre presented the following slides: http://www.ietf.org/proceedings/09nov/slides/xmpp-2.pdf -- No feedback on list, only stpeter and Sean have read Hildebrand: Getting lots of questions from IETF people about e2e stuff. -- Having trouble finding an approach that works -- Might solicit some feedback from developers Resnick: We've had discussions about this -- Couple of orthogonal things -- E.g., implementability in limited environments (like Javascript) -- Need to separate that from user adoption issues -- User adoption tends to be about key mgmt => need a leap of faith -- ... like with OTR Hildebrand: Let me try to enumerate axes 1. Object vs. stream (requirements for off-line, network failure tolerance) 2. Key management: Presentation/communication and discovery -> If we had XML format for certs, it would be really helpful Barnes: XER? Russ: No. -- Roach: In looking at stream vs object, should think about inter-protocol as well -- Also argues for object-based Hildebrand: Need to do it for at least one protocol, that might make it non-doable Roach: Just want it to be a consideration Hildebrand: Agree that it's a consideration, even a preference ================================================================================== Kurt Zeilenga (channeled by the chairs) presented: http://www.ietf.org/proceedings/09nov/slides/xmpp-6.pdf -- XEP 274 has design considerations -- Currently planning on experimental XEP -- Bring to IETF? Russ: Who is validating these signatures? Hildebrand: Don't know Peter: Really just design considerations right now. This might be used, e.g., for syndication Kurt: any entity can sign, any entity can verify Hildebrand: It's possible that we just roll these considerations into e2e. Maybe just another axis. Russ: One thing that was interesting in S/MIME was order of operations. Concerned about discussing signing/encryption in different places. Peter: RFC 3923 covers both, makes sense to do it again. Kurt is trying to get discussion going. Hildebrand: Any objections to doing signature work at the same time as encryption? -- None raised