Minutes - XMPP IETF 84 - Tuesday 31 July 2012 - Vancouver, CA Summary: Meeting materials available at http://www.ietf.org/proceedings/84/xmpp.html -- End to End Encryption Matt Miller presented draft-miller-xmpp-e2e-02. The sense of the room was that this draft is on the right track. There are some minor issues with JOSE concerning key wrapping and base64url that Richard et al will take to the JOSE meeting. -- Federation/Domain Name Assertions Matt Miller presented on draft-saintandre-xmpp-dna-00, draft-miller-xmpp-posh-prooftype-01, draft-miller-xmpp-dnssec-prooftype-02. The drafts were well received in general. The next steps are to get more feedback from the broader XMPP community (including the XSF), get feedback on POSH and DANE from security and apps areas, and encourage experimentation by implementors. The drafts may need more precision for implementors to experiment. -- Internationalized Addresses Peter St. Andre presented the current status of draft-ietf-xmpp-6122bis-02. This draft is still mostly waiting on the PRECIS framework. The group discussed the use of confusable tables vs limiting names to match local scripts. --------------------------- Raw Notes from Mary Barnes: IETF-84 MEETING NOTES XMPP (IETF 8 - Vancouver, CA) - Tuesday 31 July 2012 1520-1650 -- Status and Agenda Bashing -- 10 min (Chairs) SIP-XMPP mapping: -- draft-saintandre­‐sip­‐xmpp­‐* (expired) -- First four docs close to done. WG should continue reviewing and figure out what to do? --- DISPATCH, XMPP, AD sponsored End to End Encryption (Matt Miller) -- 15 min http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (Note: Draft may also be discussed in JOSE) To do: -- Signing -- Notes about sender offline -- Optimizations with ? Richard: thinks this I son the right track. Use of JOSE is kind of a hack, but that's because JOSE wasn't designed for this usage. Matt: issue is around key request Richard: because JOSE doesn't define wrapped keys as a first class, thus you have to treat key as content . Doc does a good job about what needs to be changed with Jose. Joe: need to follow up with Jose – make sure they understand Richard and Matt will do that tomorrow in Jose session. Jabber room (florenz?) – don't know much about Jose – base 64 URL is different… Matt: could find a way about that one. As far as JSON since trying to use encrypting and signing. Joe (on the floor): agree Richard: It's in the Jose charter to use JSON Domain Name Assertions (Matt Miller) – 45 min http://tools.ietf.org/html/draft-saintandre-xmpp-dna-00 http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-01 http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-02 (Note: *-dnssec-prooftype-02 may also be discussed in DANE) Federated identity delegation thing. Two problems: 1) Secure delegation 2) Identity verification Today delegation done by DNSSRV. DNSSEC Helps - Joe: WG should consider which names in DNS are valid in PKIX world? - Identify verification : - What is verification materials? (certificate, token.._ - What are the matching rules? (RFC 6125?) - Where do you get material? (PKI, DNS. …) - Do you need secure DNS to trust this material? - Prooftypes: - the entity asserting its identify needs to prove the association using a recognized… PKI prooftype - verification material: PKIX cert - matching rules: 6125 - Source: PKI/trusted roots - Secure DNS: nice but not necessary - Wes: it helps a lot more if you're expecting it to help with validation of cert. The other part of DANE locks you into the CA you wanted. Matt: it's what we have today. Dialback Prooftype - verification material: token - matching rules: depends on implementation, but typically byte by byet - source: sent over XMPP itself - Secure DNS: needed in order to really trust the information Joe: do you think we would have a policy in the future to say don't do Dialback? Matt: It is a trustworthy model. DANE Prooftype: - verification: PKIX cert - Matching rules: SubjectPublicKey Info or hash - Source: DNS - Secure DNS POSH Prooftype: - verification: PKIX - matching rules: 6125 - source; https - secure DNS: nice but not necessary Joe: do you think there will be a way to indicate POSH with bit in cert? Matt: want to make this immediately deployable – adding a new bit wouldn't allow that. Joe: maybe carry over XMPP . Concern is checking URL when only one server might support. Matt: there are optimizations. But, this doesn't require a ton of code. Operators understand how to put a file on their servers Wes: Did you consider case where there is no server running and FW in place and you never get TCP response? Matt: that's been mentioned. It depends upon whether we want to do the signaling. Not important for 3 or 4 – maybe so for 25. Don't know how long lived connections will be. Not so concerned about long time outs. Wes: the client is waiting. Matt: could be doing a DANE connection. Most SSL libraries let you hold off. Wes: happy eyeballs Standalone servers: - Use PKI as you do now - USE DANE with secure DNS - Use dialback keys, preferably with secure DNS - POSH not needed, but OK Virtual hosts: - PKI is not a realistic option, so…. - Use DANE with secure DNS (preferred in long term) - USE POSH (not as elegant as DANE but immediately deployable) - Use dialback keys (preferably with secure DNS) Next steps: - XMPP community (WG+XSF) feedback pn DNA framework - Get feedback on DANE and POSH from security and APPs - Experiment with implementations Wes: if you are going to go down these steps, you need somewhere a framework document indicating what you are going to prefer. OTW, you could get one to validate and another not. Matt: Yes - They validate differently. Do have a framework draft. Peter SA: would prefer DANE Chairs: - like idea to experiment with implementations Richard: likes to experiment with implementations but don't think it can be done with current doc – need more precision Joe: within XMPP community (WG + XSF), we need to get them to hear this. Address Format Internationalization (Peter St. Andre) -- 10 min http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-02 Remaining work: - 1) Processing order: perform normalization first - 2) Map full-width and half-width code points to their decomposition mappings? - 3) Error handling: add a sentence about using (might go in 6120bis) 4) Wait for PRECIS framework to be done 1 & 2 are remaining open issues. Will wait for WG feedback on 3. Discussions tomorrow on 4. Discussion: Peter: issue with registration of names that look like others. Joe: may want to consider here or PRECIS if you wanted to use new .Don't register two names with confusable mappings. Peter: this is outside scope of what we do - have to say you can't run script through JID. Joe: can't use codepoints in confusable table. Before you allow reg of a name in your domain, run the confusable mapping and do a check. Peter: like that approach Matt J: is the problem mixing of scripts? Joe: that's one of the possible things. Think the algorithm is not easy to describe. Matt M: the idea of the confusable table – the more I think about it, it makes sense. If something can get confused, that's probably the right way to go. Joe: would add another column to table with JIDs – that would be unique Ben: agree. Peter: think will allow certain characters depending upon domain. Likely won't allow codepoints that its script is not familiar with. Joe: don't concede the point yet. Run server with people from multiple countries. Has multinational companies on server Matt M: don't think this should be formally codified – maybe provide guidelines Bernard: agree. Have done this with multiple countries./scripts. Concentrate on things that cause real security problems. Peter: this seems to be an SP policy decision. Joe: the confusables check would have gotten that. Peter: don't think mixed script is that hard. But, confusables seems to be a good way to do it. Matt: this needs to be dealt with by servers as much as possible. Clients should not be enforcing this . Joe: not sure how to tell if given string of codepoints is all from one script. Matt: with current rules, have no way to do normalization. Jonathan lennox : the whole case normalization problem – it's still unclear how a server can enforae all lower case. It's easy for a cooperative client to follow rules, but hard for server to enforce because it depends on the locale. Joe: take that to PRECIS -- AoB and Open Discussion -- Any remaining time and energy ------------------------------- Raw Notes from Wes Hardaker XMPP IETF Meeting Minutes -- 2012/07/31 ======================================= Date: 2012-07-31 Tue Table of Contents ================= 1 draft status 1.1 sip-xmpp mapping 2 end-to-end encryption -- XMPP E2E -- Matt Miller 2.1 comments/discussion: 3 Domain Name Assertions -- Matt Miller 3.1 Comments: 4 Address format internationalization -- Peter Saint-Andre 4.1 Comments 1 draft status =============== 1.1 sip-xmpp mapping --------------------- + first four near done, just need final review 2 end-to-end encryption -- XMPP E2E -- Matt Miller =================================================== + changes from -00 listed + key wrapping + have 2 keys; 1. for messaging content and 2. one to encrypt the messaging key + hopefully addresses some concerns + The content message key (CMK) is sent encrypted using the session master key (SMK) + todo + signing + sending offline + optimizations with 2.1 comments/discussion: ------------------------- + Richard Barns: feels like a hack in parts + Matt: biggest hack is near key wrapping + Richard: because JOSE doesn't define wrapping keys, you have to treat the keys as content which is the problem. This document declares what needs to change in JOSE. + Joe Hildebrand: JOSE needs to understand that so please bring it up in the JOSE meeting tomorrow. + Florin: do we have any chance getting around base64 URL which is different than base64 everywhere else, including JSON + Matt: we could certainly get around base64, but we can't get around JSON + Joe: we can't get around json because it's in the charter, and JOSE was charted to do this work for us. 3 Domain Name Assertions -- Matt Miller ======================================== + problems: 1. how do I get to the right server? 2. how do I check the credential of the server? + delegation + we use SRV records + but host names can be different in the SRV record from the hosted server name + DNSSEC can help assure us that everything is correct + useful for very large server farms (eg, gmail) + identify verification + prooftypes and 4 options + PKI: certificate and the name must match + DNSSEC is nice but not necessary + Wes Hardaker: DNSSEC may be needed to validate or to check that you're using the right CA + Matt: yes, but I'm listing this as what we have today not what might be good in the future + Dialback + verification material is a token + ideally needs dnssec + Comment from Joe: + would we recommend policy at some point? IE, don't do dialback if DNSSEC is available + DANE (DNSSEC prooftype) + verification is a hash of the public key info + dnssec is necessary + POSH + verification material: PKIX + passes the material over HTTPS + Joe: are we going to need an extra pkix extension to indicate that you can check POSH? Otherwise how are they going to know when to check or not, or check everybody? + matt: the point is to make this as immediately deployable, so an extension isn't quick + Joe: I don't want to waste the network connections, etc, when I don't need it. + Matt: we could optimize, but we don't need a ton of code and ops can already place files somewhere. It's straight forward. + Wes: + what about TCP SYN drops to servers that aren't running https and thus the connection establishment is slow. + matt: That's been mentioned, but I'm not concerned about the delay. + stand alone servers + use PKI as now, dane as needed, posh, and then dialback + next steps + need feedback 3.1 Comments: -------------- + Wes Hardaker: you need a document somewhere that specifies which options to prefer, etc. + Matt: there is a framework document that the decision making discussion could go into. + Peter/Jabber: I think we'd prefer DANE + Richard Barns: I like the idea of implementing it, but I don't think the current documents quite give me enough details to implement yet. 4 Address format internationalization -- Peter Saint-Andre =========================================================== + -01 changes + I think people are on board with doing NFC, but I need to know if that's not the case + based on list discussion, changed SHOULD to MUST for A -> U labels + based on list discussion, enforcement rules specified + remaining work + not much remaining except for PRECIS framework that needs to be finished. + PRECIS is different in terms of IDNA processing order + the PRECIS work really needs to get done 4.1 Comments ------------- + Joe: we're happy you're doing the IDN work and I think people appreciate it. + Peter: we might want to define a policy for a service to disallow unicode characters that match ascii ones and are too similar + Joe: we might want to put something in a document to describe what to do in cases. + Peter: the sledge hammer approach of deny everything is easier than using a "confusable table" + Joe: what I mean is use the confusable mapping to check if something exists and is similar or not. I'm not sure the algorithm is easy to describe though + Matt: the idea of the confusable table first bothered me, but it makes more sense now. + ben: I agree on this, ascii only would be easier but if everyone did that then all this work is for not + joe: I run servers than have multiple cultures and enforcing policies is problematic + matt: I don't think this is good to formally codify, but it's good as operational notes. + ... + matt: it's a policy issue the client should never enforce + joe: I don't know how to make these code points all be the same for all of it. + matt: for the current rules I don't have the ability to do this today + johnathan: the whole case normalization problem is hard for a server to enforce things like "all lower case". It's easy for a cooperative client to follow the rules, but it's very hard for the server to enforce. + that's a PRECIS problem.