Minutes - XMPP IETF 81 - Tuesday 26 July 2011 - Quebec, QC, CA Summary: -- Domain Name Assertions/Server Connection Reuse Richard Barnes and Eric Rescorla presented slides on use of DNSSEC and PKIX based authentications, as well as how to use a single connection to support more than one hosted domain.  Discussion seemed to lean towards certificate based approach. We need a decision about DNSSEC vs certificates. Discussion to continue on list. We need a draft showing Ekr's proposed certificate based approach. -- Internationalization/XMPP address formats Peter St. Andre presented the current state of 6122bis. This is still dependent on the output of PRECIS, and on Peter and Marc's framework document acceptance as a PRECIS work item. -- End to End Encryption Matt Miller presented slides on end-to-end encryption. We depend on WOES for object details. Matt will try to update the (now expired) end-to-end draft to capture current thinking. -- Dependencies Chairs once again exhort everyone who is interested to pay attention to PRECIS and WOES. Raw notes from Cary Bran and Paul Kyzivat follow: ------------ Cary's Notes ----------------------- -----------XMPP (IETF 80 - Prague) - Tuesday, 29 March 2011 1520-1810 http://tools.ietf.org/wg/xmpp/ Status and Agenda Bashing – Joe Hildebrand and Ben Campbell * Co-meeting with GeoPriv running until 10:15 * Note Well Overview * Group Information - Mailing list xmpp@ietf.org * Blue sheets XKCD *Agenda - http://www.ietf.org/proceedings/81/agenda/xmpp.txt  http://www.ietf.org/proceedings/81/slides/xmpp-0.pdf ***************************************************************** Richard Barnes - XMPP DNA Options http://www.ietf.org/proceedings/81/slides/xmpp-1.pdf Outline options - incorporating stuff from various sources including EKR Overview of DNA Problem Slide    See slide for problem overview Draft outline slide - hosting provider only has to have a cert for his own name, not customer names        - Mux - dialback plus DNSSEC SRV checks Is there a problem slide - Cert example - amazon.com phishing scheme Solution Outline slide * Skipped Flow Slide Trade-offs Slide What to do Slide ***************************************************************** EKR comes up to speak Slides? Follow up on AI from last meeting Problem Statement - per Richard Barnes Slide How to provide a certificate that can only be used for XMPP The technical perspective unlikely to be confused with a any other kind of cert Clients could be modified to detect the certificate Putting it together Richards slides Certificate by server name indication - see Richards slides Joe H - could you talk a bit about how this maps to the multiple domain pairs Richard Barnes - auto to first domain you want to talk to on the server, then you get the domain pairs EKR: GoogleVoice->RTF.com given SRV record - guy can display both certificates to prove that the are Fluffy: Clearly nuts - trust one person to upload a private key, going to trust them to upload all their private keys - EKR: Absent CSP validations - months, revocation story is better with DNSSEC Fluffy: Dogma - use EKU, EKU will never be deployed.   EKR: People that need to implement EKU are not you and will not be deployed Paul Hoffman (tourist question) - hosting services don't want to hold your certificate, if host name has "xmpp" semantic, that should make the say that I am not holding their "real" certificate   JH - responded requirement for jid to be the same as email address that's why Johnathan (tourist question) - PSEC verification question - EKR answers What to do: Need a document Flow overview from Richard Barnes preso: Walk through of flow Discussion of flow with Joe H, EKR, Richard Some work will be needed here - straightforward work in the pks only version or change to dnssec Joe calls for clarifying questions on this: St Peter: Proof point in pks, wanted to know where we were going Joe: Less options more interop St Peter: Pkixs? Dnsec - extra goodness Ricard/EKR - no extra goodness St Peter: hard for folks to source these certs CA signings Paul Hoffman: EKU - has been abandoned, takes a long time just to change a bit Fluffy: ViPR - weirder certs than this - godaddy is doing this strangeness for ViPR, CA would do this Richard: CA procedures to issue certs is the hard thing, changing requirements is the hard thing bernard aboba - chatted with this group about issues AI: get proposals a bit more concrete, something needs to be done, sit down and figure out the flows Joe, EKR, Richard XMPP Address Formate Peter ST Andre http://www.ietf.org/proceedings/81/slides/xmpp-2.pdf Recap - slide 6122bis - Slide Not subclassing the "FreeClass" Domainpart slide trying to maintain backward compatibility as much as we can Localpart slide Resourcepart slide XMPP Open Issues 1 Slide What do we do with different unicode versions? Do we want a way to discover the unicode versions Ted Hardie: does no good to discover the version if you couldn't do anything about it, prefer not to track versions, bad path, could be eaten by bears.  You don't need to know which bears are eating you. Discussion about version discovery Paul Hoffman - as long as you are not changing your processing rules for unicode, you should be okay, if your code can't handle that, there is a problem with your code Peter - migration from stringprep world to precis world Joe H - make one change to our processing rules will vastly improve interoperability.  Today all assigned codepoints are invalid There are many dragons XMPP Open Issues 2 Slide ***************************************************************** Matt Miller End-2-End Object Encryption Current Status - Slide Problems - Slide Big Ideas - Slide Discovering Support - Slide Distributing Keys - Slide Encrypting… - Slide Still Encrypting - Slide Encrypted - Slide Insert Woes Here Decrypting - slide Decrypted - Slide Signing - SLide Similar process Still Signing - Slide Signed - Slide Verifying - Slide Mix-n-Match - Slide Caveat Emptor - Slide Open Issues - Slide Question from chair as floor Bitdown attacks possible? Joe WOES BOF - today at 3:30 End 2 end for xmpp == interest in bof Paul Hoffman - question about signing vs encrypting key - can you differentiate Richard Barnes - Document with details? Kurt - my only comment which Matt is well aware of, is to make sure that the key exchange supports, to the extent reasonably possibly, other XMPP signing/encryption extensions... including different key formats (including certificates). Matt - Noted…. Joe calls for close Peter - go to woes and precis Charter discussion at Woes. ----END MEETING ----------- Paul's Notes ------------- These notes are really rough. I hadn't read any of the drafts and so it was difficult to capture the significant points going on. But here is what I got. ================================== XMPP DNA Options: Richard Barnes: Overview of the doc - describes a couple of mechanisms. =================================================== EKR then talks on DNA Authentication Alternatives: Seems to be more detail of one of the alternatives Richard mentioned. ========================================= Discussion on both of the above: Cullen asked how you would revoke and how long it would take. EKR says its better with DNSSEC. Paul Hoffman asked why hosting provider minds holding cert that is specific to xmpp. But the answer is that you want your xmpp addr to be exactly the same as your email addr. Jonathan Lenox asked something and got an answer I didn’t follow. EKR says a document IS needed. Then discussed call flow in Richard’s document. Discussion between Richard and EKR. Variations on this were mentioned having to do with the initial connection establishment. EKR: some work will be needed if we go EKRs way, but not with DNSSEC. So he wants a decision on which way to go. Someone raised issue that it would be difficult to get special certs from CAs. Paul Hoffman gave an example of how difficult this can be. Cullen gave example from ViPR where it was possible to get weird certs from godaddy. Bernard Abboba said he thought getting weird certs was a function of the procedures the CA must follow, not what is in the cert. Richard, EKR, and Joe to work together to get a proposal together. =============================== XMPP Address Format: st peter: Open issues: full vs half width code points; how to discover Unicode version; how to handle i18n errors. Ted questioned tracking Unicode version because can’t do anything about it. (You don’t care what kind of bear is eating you.) Peter says there have been discussions on this. In a future version he will incorporate that. Paul Hoffman made a point about Unicode processing that I can’t describe. Joe: if we make one change to our processing rules it will improve compatibility. If a code point is not defined in your version of Unicode, assume it is from the future and try to process it with some generic rule. Jonathan Lenox: raised issue about mapping to lower case, because it is locale dependent. Open issues: must client be compliant or will only the server enforce the rules? Define registrar-like policies for servers? Do we need a migration plan? ======================== E2E Object Encryption: (Discusses problems with key distribution and management.) Ben asked if XEP was ok regarding bid down attacks. Joe answered that some version of this was “relatively” safe from bid down. Paul Hoffman asked if encrypting and signing keys are assumed to be the same. Answer that this assumption isn’t made, still vague. But was agreement that there needs to be a way to distinguish encrypting keys from signing keys. From jabber room – request to ensure that other key formats are also supported.