Minutes - XMPP IETF 78 - Thursday 29 July 2010 - Maastricht, NL Summary: 3920bis: Just completed 2 last calls. Minor changes from last call. Please review diffs for correctness. draft-ietf-xmpp-address: Just completed last call. Minor changes from feedback. Please review diffs for correctness. [Chair Note : The chairs and author will discuss how to progress these] 3921bis: Just completed WGLC. Several open issues discussed in meeting. See raw notes for details. Most need further discussion -- Peter will take those to the list. This draft needs more reviewers, only 5? reviewed for WGLC. Several people in the jabber room volunteered to review. Chairs took names and will follow up :-) Domain Name Assertions -- Richard Barnes presented a DNS based alternative. This is different than what is currently described in draft-ietf-xmpp-dna-00. There was lots of interest in room, but need for actual text, then further security expert review, as well as further review in the work group. [Chair Note: The chairs and authors will discuss how to move this forward.] [Raw notes follow. These came from the jabber stream, as Aaron Stone ()scribed for both minutes and jabber. Logistical messages and off-topic banter elided for brevity. The full jabber log is available at http://www.ietf.org/jabber/logs/xmpp/2010-07-29.txt ] ------------ [09:32:20] Tobias has set the subject to: XMPP WG | http://tools.ietf.org/wg/xmpp/ | Agenda: http://www.ietf.org/proceedings/78/agenda/xmpp.txt | Audio: http://videolab.uoregon.edu/events/ietf/ietf786.m3u [13:15:03] coming to session at 4:15, ben and joe chairs, i am scribe [13:15:05] note well. [13:15:08] agenda. [13:15:26] status: 3920bis and 3921bis WGLC concluded [13:15:35] xmpp-address concluded july 13 [13:15:56] agenda bashing: use a larger font. [13:16:21] st. peter puts up slides, come to mic [13:17:05] st. peter runs through 3920bis and address splitoff WGLCs [13:17:51] wglc on -10 early july, second wglc on -11 late july. [13:18:07] next slide: ambiguities about handling of silent peers [13:18:59] ambiguities: number of streams, number of TCP connections, direction of each stream [13:19:35] sometimes silence means the other entity hasn't sent you any stanzas in a while. sometimes it's because it's just quiet. other times it's because the connection is lost but you don't know it yet. [13:19:58] st.peter does not see this as a big deal, the current text covers this well enough, gives information/guidance. [13:20:08] next slide: addresses [13:21:08] addresses are an xml body. we have handed off to stringprep how these addresses are represented on the wire. meanwhile, email addresses are no longer going to use stringprep, but will use some new idna thing. [13:21:30] so we'll have our own spec in a separate doc to have a stable spec. [13:22:03] next slide: ACE labels, mixing character sets, implementation details. [13:22:45] description of phishing attacks when idna is used to mix character sets where the visual appearance is nearly identical [13:23:26] next slide: 3921bis [13:23:47] I'm just in shock that Peter's managed to put more than on word on a slide. [13:24:31] 3921bis is in WGLC. just a few small issues have been raised. only 5 people have commented. more comments desired. a few issues remain open. [13:25:33] chairs plea for additional reviews during WGLC, will continue to accept reviews even though WGLC is formally closed. [13:25:48] MattJ raises his hand [13:25:48] I can do. [13:25:48] i'll review it [13:25:52] chairs looking for a show of hands for review volunteers. [13:25:53] It's an easier review than 3920 was [13:25:54] o/ [13:26:05] I'm halfway through already, but I've been pressed for time (started new work this week) [13:26:12] Joe Hildebrand, Four. [13:26:42] chairs are in ur chat room, loggin ur handz volunteerin. [13:26:53] next slide: presence probes [13:27:14] this was loosely specified in 3921. what do you do if you ping for presence, and the user is offline? [13:27:33] some servers say, "yep, he's gone." others just ignore you. [13:28:32] this has a significant impact if your server is constantly replying to requests for offline status. [13:29:18] current text uses SHOULD with respect to a server replying to these messages. [13:29:49] st peter believes that consensus is on SHOULD, and there isn't a compelling argument or consensus for MUST [13:29:52] Well, I'm in favour of it being a MUST, too. [13:30:10] next slide: presence optimization [13:30:15] Because of cleanup considerations, mostly - otherwise you end up with timers and all sorts. [13:30:25] I'm in favor of it being a MUST as well. Same reasons. [13:30:34] Dave Cridland/waqas: did you reply to kev on the list? i'm out of sync there. [13:30:50] Joe Hildebrand, I didn't, actually. I should do, you're right. [13:31:00] I may have replied to the old thread, but not to the new one. [13:31:00] :) [13:31:15] please reply to the current thread, so we can re-judge current consensus. [13:31:30] I'm -1 to MUST, I'll post to the list [13:31:31] st peter is currently probing my server for status. i'm proving st. peter's server for status. but my server knows i'm offline and is ignoring peter's server. [13:31:56] peter's server might now consider not telling my server that he's online, since i'm not online either. [13:32:07] Ralphm: Yes, that's what I argued on list. [13:32:12] ralph at mic: doesn't this seem fragile? [13:32:19] What servers are known to use this optimisation? [13:32:31] (the one currently in discussion) [13:32:32] Given Jonas's response, I'm asuming Google does. [13:32:41] MattJ, M-Link does, actually. [13:32:42] MattJ: i think XCP does as well [13:33:42] st peter wonders if we should gather information on which servers do this [13:34:50] current revision says the a server SHOULD send presence updates only if the remote server bothers to reply to probes. stpeter's working copy uses MAY, since we probably don't want to push implementations in this direction, but want to continue to allow those that do. [13:35:00] no clear consensus yet. [13:35:03] What I suggested on-list was: [13:35:31] We could encourage always sending in 3921bis and allow another document to list lossy performance enhancements like this. [13:35:46] so SHOULD always send in 3921bis. [13:36:40] I think what Kevin said is reasonable. [13:36:56] Ok. [13:36:56] chairs: let's continue on the list [13:37:16] [Getting confusing that I'm replying to the stream before the scribe has scribbed :) ] [13:37:45] [guess the audio latency isn't too bad this time. :) ] [13:37:48] stpeter: 3920 has guidelines about how a server handles incoming stanzas. 3921 has more detailed rules about what to do with each stanza. in 3921bis, there's even more detail. [13:37:54] Kev, Weird. Usually there's sufficient audio lag that that's impossible. [13:37:56] one new detail is what to do with headline messages. [13:38:22] Collecta uses stanza errors to detect bad recipients. silently dropping the stanza may cause us to send event notifications unnecessarily. (granted, I don't think we use type='headline') [13:38:59] Jack Moffitt, That suggests that if you care, you'll keep using chat/normal rather than headline. [13:39:02] don't many pubsub implementations use type='headline' for notifications? [13:39:04] the semantics were not well defined for headline messages. over time, we've thought more about it, and we want to broadcast this information. full jid. could use for pubsub. [13:39:23] so what happens if it goes for a full jid, but the resource is offline? [13:39:28] for pubsub, it's still nice to get the error, so you can unsub. [13:39:29] if that's not the case, then no need to worry. [13:39:30] silently drop, or return an error. [13:40:04] Joe Hildebrand, Why do you want to unsub, though? PubSub isn't (always, or usually) tied to presence. [13:40:20] Waqas raised returning an error - I discouraged, I think :) [13:40:23] I want to note that pubsub is specced against Core, not IM [13:40:32] PubSUb being [xep 60] for those who wonder. [13:40:44] dave: yup. that's how i decided to say it out loud. :) [13:40:50] if you're using xmpp for pubsub, you want the error so that you know to unsubscribe. [13:40:52] Dave Cridland: Box horribly overloaded. [13:41:02] Kev, So it is. Harrumph. [13:41:09] so we're at handling being dependent upon what you're using headlines for. [13:41:21] and the receiving server doesn't know what the sending server is expecting. [13:41:22] Joe Hildebrand: I'd wonder if maybe there should be a wayfor pubsub to probe, a message error need not be permanent. [13:41:43] Dave Cridland: XEP-0060: Publish-Subscribe is Standards Track (Draft, 2008-09-03) See: http://xmpp.org/extensions/xep-0060.html [13:41:44] and also I want to point to AMP [13:41:46] I assume if the JID oesn't exist at all, *that* returns an error. And if that's the case, I think I'm fine either way. [13:41:51] Kev: you can always direct a presence to a presence service. [13:41:52] I think pubsub services should have headline/normal type configurable. Headline also doesn't go to offline, traditionally, whereas normal does. [13:41:52] Do pubsub implementations really send to full JID? I'd expected bare... [13:41:58] that allows for sending along your intentions [13:41:59] Florob: PEP [13:42:07] Florob: PEP does. [13:42:08] take to list. [13:42:17] Florob, Depends. PEP, and a full-jid subscription to a [xep 60] service is legal too. [13:42:17] Dave Cridland: XEP-0060: Publish-Subscribe is Standards Track (Draft, 2008-09-03) See: http://xmpp.org/extensions/xep-0060.html [13:42:17] next slide: subscription related presence stanzas. [13:42:49] Dave: we totally need more things to configure. :) [13:42:59] Joe Hildebrand, "Make it an option!" [13:43:02] One thing I noticed from jabberd2 implementation is that it never cached the actual XML [13:43:10] 3920 is silent on what to cache. [13:43:22] so there is no way to extend that part of the protocol in that implementation. i'd recommend against allowing that. [13:43:31] there are some server out there that cache roster pushes, and also unsubcription notices. [13:43:41] but the text is silent on the issue. [13:43:42] jack: what's "that" in your last? [13:43:43] AMP == XEP-0079 [13:43:47] should we add a note about this? [13:43:56] !xep 79 [13:43:56] Dave Cridland: XEP-0079: Advanced Message Processing is Standards Track (Draft, 2005-11-30) See: http://xmpp.org/extensions/xep-0079.html [13:44:23] allowing servers to cache the fact that it got an unsubscribe, without actually caching the rest of the XML that was sent (ie, any extended children, etc) [13:44:26] stpeter: my tendency is to add a note about this. [13:44:39] jonas at mic: is this a requirement for roster versioning to work well? [13:44:48] what are the benefits of this caching? [13:44:52] Jack Moffitt, Right, so cache the stanza, not the state (which is cached already). [13:45:15] stpeter: it's not required. it can be helpful for the client to see the unsubcribe message so that it knows why the roster has changed since the last time it logged in. [13:46:30] ideas about roster versions with timestamps [13:46:43] chairs: consensus sounds easy to get once we have some text. [13:46:45] Ah, delay stamping, yes. Which is [xep delay] [13:46:45] Dave Cridland: Multiple matches: XEP-0203: Delayed Delivery, XEP-0091: Legacy Delayed Delivery [13:46:59] (New and old), there. [13:47:10] next slide: presence probes are traditionally for people on your roster. [13:47:15] Someone stop Peter talking :) [13:47:18] but they might be useful for other things! [13:47:30] like, sending presence to a chat room [13:47:37] chat room thinks you're there [13:47:42] server might want to double check that [13:47:45] isn't it now [xep 203] [13:47:45] Joe Hildebrand: XEP-0203: Delayed Delivery is Standards Track (Final, 2009-09-15) See: http://xmpp.org/extensions/xep-0203.html [13:47:55] Joe Hildebrand, Yeah, it listed both. [13:48:08] ah, yes. [13:48:13] So this responding to probes when you've sent directed presence thing. [13:48:13] [rfc 3920] [13:48:13] rbarnes: rfc3920: extensible messaging and presence protocol (xmpp): core (october 2004) See: http://tools.ietf.org/html/3920 [13:48:18] ooh, that was fun! [13:48:19] open question: do we need both parts of the final clause of this sentence? [13:48:42] I looked at implementing, and the interesting thing is that it moves directed presence from being per-resource to being per-account, which is quite a major change. [13:48:44] Answer: I don't see a reason that we disallow sending probes. [13:48:48] "the server MUST NOT send a probe to a contact if the user is not subcribed to the contact's presence... unless the user has sent directed presence to the contact _and_ has received presence information in return" [13:49:01] And the second part of that clause is bogus. [13:49:06] The recipient of the probe is going to choose not to answer in many cases, but it's easie to leave the option of sending them open. [13:49:12] Kev: I don't either, but i think it's reasonable to ask people not to send them in order to be good network citizens. [13:49:24] But I think it's not likely to be a big traffic burden in current networks. [13:49:26] ralph: we should drop "and has received presence information in return." [13:49:41] Jack Moffitt: Asking people not to do things that they don't need to do seems a bit odd. [13:49:51] Kev: fair enough. [13:49:51] I'm not clear on why the "MUST NOT" - what's the worst that could happen if the server /did/ send a prove? [13:49:53] It's a bit like asking a server not to make up messages to send to people without a reason. [13:49:53] *probe [13:50:27] MattJ: also good point. Seems like SHOULD NOT would not hurt us here. [13:50:38] Jack Moffitt: Even SHOULD NOT seems unnecessary. [13:50:50] Kev, agreed [13:51:19] stpeter: something that the text doesn't capture is that this should apply to the probeb user, and not the probing user. [13:51:24] will propose text on the list [13:51:28] next slide: todo [13:51:41] add text about "id" attribute on presence subcription re-sends by server [13:51:54] define impact of presence errors on roster state (if any) [13:52:09] stpeter has not looked into these yet, but will propose text. [13:52:13] next slide: next steps [13:52:26] please review diffs to ensure correctness in the most recent drafts [13:52:43] stpeter will post a new version of latest drafts on saturday, maybe today or tomorrow. [13:53:07] please give reviews of 3921bis, wglc still going. [13:53:48] stpeter may be leaving this room soon to give another set of slides to some other group [13:54:07] st peter: in 3920, we had some text about checking server identity when connecting to a server. [13:54:24] e.g. checking certifications, DNS, SRV name, etc. [13:54:38] every protocol that uses TLS has its own text about this. and they're all a little different [13:54:51] jeff hodges wrote a draft a few years ago for general guidelines. [13:55:17] (FWIW, ACAP, POP3, and IMAP all share the same method, since they originated in the same draft, but that's a rarity). [13:55:27] stpeter has taken the document on, and they're working on a document that covers what application protocols should do with TLS in general [13:55:37] draft-saintandre-server-tls [13:55:48] note that we have created a normative dependency on this document. [13:55:52] please review that one, too. [13:56:05] because if you don't, 3920bis will sit in the RFC Editor's Queue FOREVER. [13:56:18] next speaker: richard barnes. [13:56:26] slides about xmpp dns draft [13:56:41] aaron.stone.scribe: s/dns/dna [13:56:42] problem space: example.com outsources xmpp services to example.net [13:56:55] SRV: _xmpp._tcp.example.com -> example.net [13:57:39] so we want secure delegation, the client should be sure that it is talking to example.net and that it's been authorized by example.com. [13:58:02] next slide: approaches to solution [13:58:19] bernard at mic: you've left out a solution, the "official" one by the pkcs wg [13:58:55] Right, the reasoning with the sRVName not being used is that it means redoing your certificate every time. [13:59:39] (note to self, listen to this audio again, i didn't get that) [14:00:04] bernard: there's a requirement that people don't appreciate [14:00:21] there was says to do this that everyone will accept, and ways to do it that everyone won't accept [14:00:39] the question is whether the trust anchor of the trusted site is trusted by the client [14:00:47] Bernard, when you get back to your chair, let's discuss this more. I think you're misunderstanding the problem that's being addressed by DNA. [14:01:35] or if the server asserting the third party service is trusted tells the client how to trust the other server in full [14:01:45] st peter has left the building. [14:01:52] Surely the right answer for all this is just to use the DNS approach, which makes the entire problem go away. No? [14:01:52] back to richard on mic [14:02:01] richard wants to use dns [14:02:12] Oh, that's what he's trying to do. Never Mind. [14:02:14] next slide: observation, dnssec fixes things [14:02:14] But if I caught that bit Joe Hildebrand was saying, then yes, we select certficate based upon the to attribute of the stream header, so certificate selection isn't a problem either. [14:02:56] if the srv record is signed, then we're in good shape: we know that the pointer to the service provider is trusted [14:03:05] client still needs an appropriate trust anchor [14:03:22] next slide: bringing the gap [14:03:39] if the problem is a missing TA, supply it at the application layer [14:03:40] which way do the names go on srvname? [14:03:40] And yeah, I thought that DNSSEC was basically the solution here. Initially, we didn't think this was the case, about a year ago when we tossed this idea out. [14:04:04] is [14:04:11] Joe Hildebrand, For the sRVName subject alternative name, you mean? Or in the SRV DNS RR? [14:04:12] In Feb we vaguely agreed that DNSSEC was the wrong approach, because it'll be a cold day in hell before the root gets signed... [14:04:13] is the CN example.com or example.net? [14:04:24] Kev, Quite chilly, now, isn't it? [14:04:24] I think we can revisit. [14:04:28] next slide: overall process [14:05:06] Kev, Hell, or DNSSEC? [14:05:09] richard steps through this slide. [14:05:13] Dave Cridland: yes. [14:05:31] Someone also raised that signed via DNSSEC != valid [14:05:59] if we have dnssec, we're golden. if we don't have dnssec, then the application has a backup plan [14:06:26] asking the service provider to provide a cert signed by the client site. [14:07:16] next slide: pros and cons. [14:07:20] bunch of pros. [14:07:28] Does this mean that the application has access to the full DNS data and so on? I've heard many times that that is hard to get to, and this seems like a counterexample. [14:07:38] cons: requires application control of dnssec TAs. [14:07:50] con: requires binding between certificate and dnssec key pairs. [14:08:03] richard is not sure if these are showstoppers. [14:08:09] next slide: open issues [14:08:10] Andrew: this is server-side, where writing your own resolver library is much more common [14:08:20] thx [14:09:15] Andrew, Sorry, which Andrew are you? [14:09:33] oops, sorry, thought my full name was there. Andrew Sullivan [14:09:48] Andrew, Ah, that Andrew. [14:10:38] discussion on using dnssec for this purpose, interesting. [14:10:59] needs more details, needs security reviews [14:11:13] Nulani leaves the room [14:11:19] chairs note: this proposal is not a draft yet [14:11:31] there is a draft that uses a different approach, draft-ietf-xmpp-dna [14:12:10] chairs apologize for not getting to the end-to-end encryption slides [14:12:21] oh, that's quite ok with me (-: [14:12:32] chairs encourage everyone to please read the slides [14:12:37] meeting is adjourned [14:12:39] thanks everyone! [14:12:45] Joe Hildebrand, If there's no objections, the E2E stuff could be discussed online at a later date. [14:13:07] please, let's discuss online…sooner rather than later [14:13:52] announcement on the mic: the NLNET.nl is offering money to open source developers who will use DNSSEC. [14:13:53] I think. [14:13:59] dave: that looks right [14:14:25] aaron.stone.scribe, I am always right. Ergo, if it differs, he must be wrong. [14:15:00] Bernard, Got time for a chat about sRVNamr subject-alt-names?