Re: [Standards] Proposed XMPP Extension: Disco Feature Attachment
Hi goffi, Thanks for proposing this. The council has today vetoed the advancement for this ProtoXEP to Experimental, but I'd like to give you some feedback because I think the problem you're trying to address is real. The bottom of this email contains two recommendations from me which may allow us to solve the underlying issue. I think this is a symptom of a problem with a certain subset of specifications of which RSM [XEP-0059] is the most well-known. They define a generic feature which can be applied to many other specifications. However, the interaction of that feature (e.g. RSM) with other specs (e.g. disco#items) is underspecified. However, the proposed solution (including the variation proposed by singpolyma / Stephen) is in my opinion not quite as useful as it might seem on the first glance, and might actually be harmful. Here is why. Even though it may seem obvious how to combine feature X (e.g. RSM) and feature Y (e.g. disco#info), it may not be obvious to everyone, so it should still be written down somewhere. If the specification of the interaction is written down somewhere. If it is written down somewhere, that somewhere is an excellent place to put a disco#info feature string which can be used to identify that an entity supports this specific combination. That means that there is no "need" for a generic way to combine two (or more) feature strings: there will always be a specification document to accompany this. Now what next? We have the situation that RSM has a feature, but it may or may not be used in non-obvious ways with different endpoints and protocols. Most prominently, some MUC services require that you use RSM with disco#items if you want to list all MUCs, but you have no way to find out just from looking at disco#info. This needs to be addressed. In this case, this should be written down in RSM itself or in a new document which specifies RSM + disco#info interaction. This is necessary, because XEP-0030 cannot be made to depend on RSM anymore, as it is final. So it needs to be an extension. Another note of importance is that these extra feature strings only make sense for *optional* dependencies. They do not make sense for required dependencies. For instance, MAM has a hard dependency on RSM. It is thus not required that MAM services advertise support for MAM+RSM explicitly; there is simply no compliant implementation of MAM without RSM support. >From this, one can infer that RSM should not ever have had a feature string. It is not useful: RSM only makes sense in combination with another protocol. That interaction with another protocol needs to be specified somewhere, either as required dependency (such as in the case of MAM) or as an optional dependency (such as in the case of XEP-0030 / disco#items, where a new feature needs to be defined and specified). Under this premise (removing the RSM feature string), it makes no sense to have a way to combine it with anything explicitly. However. It is useful for humans to understand feature strings from looking at them, at least crudely, for debugging and developing XMPP services. Thus, it would make sense for RSM to say something like: > If a protocol uses RSM as an *optional* dependency, it SHOULD use the suffix > `#rsm-someversionmaybe?` composed with its own namespace URI as feature > string for XEP-0030 feature discovery. And recommending this kind of wording for "generic" XEPs could go into an informational XEP. Either in a separate one, or it could be incorporated into [XEP-0143]. ## RECOMMENDATION 1 - Either extend RSM or write a new document which specifies the interaction of RSM+Disco#info. - Extend XEP-0060 to add specific RSM features for the places where PubSub may support RSM. ## RECOMMENDATION 2 - Add text to XEP-0143 like the above. - Update XEP-0059 to include a notice like the one above. ## NON-RECOMMENDATION 1 - Do *not* include any specific feature for MAM+RSM, as MAM has a hard dependency on RSM and thus no extra feature is needed. I think these recommendations are more sustainable, because they do not give the false impression - that features can be combined arbitrarily and that it will be immediately obvious how they interact - that all combinations of features need to be announced Thank you for reading this long email. kind regards, Jonas [XEP-0030]: https://xmpp.org/extensions/xep-0030.html Service Discovery [XEP-0059]: https://xmpp.org/extensions/xep-0059.html Result Set Management [XEP-0143]: https://xmpp.org/extensions/xep-0143.html Guidelines for Authors of XMPP Extension Protocols signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-08-11
https://logs.xmpp.org/council/2021-08-11#2021-08-11-9c0056346fa591e6 1) Roll Call Emerging from a horrifying reading, Jonas opens the meeting a tad late. Present: Jonas, Zash, Daniel, Georg 2) Agenda Bashing None. 3) Editor’s Update - Pubsub Caching Hints have been accepted as New as per council vote - The Moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed. 4) Items for Voting None. 5) Pending Votes - Everyone except Dave on ProtoXEP https://xmpp.org/extensions/inbox/disco-feature-attachment.html A lot of discussion following up on the mailing list thread and the discussion in xsf@. An opinionated summary by Jonas is available in the thread [1]. Referring to the discussion in xsf@ [2], Jonas changes his vote to -1, with the following rationale, quoted verbatimly: > - Any disco#info feature needs to be backed by some kind of implementation text > - Even though for some combination of features the implementation may be obvious, it should still be written down somewhere, because obvious doesn't really work > - If there is text backing the implementation of a combination of two features, that is the obvious place to declare a disco#info feature string > - If there is a place where a disco#info string is written down which needs to be read by implementors anyway, there is no benefit from having a way to construct such a string; an opaque string match is required in the implementation anyway. > and to bring this to the point which IMO makes this -1-worthy: it misleads implementations and specification authors to think that they can just slap together two feature strings and it will be immediately clear what is supposed to happen there. Daniel notes that while Jonas' concerns may be valid and he even shares them, they may not completely warrant a -1 from his perspective (while respecting Jonas' choice). Georg adds that introducing a semantic separator in an opaque string is problematic. Jonas explicitly acknowledges that there is a problem to be solved regarding the discoverability of optional RSM for various protocols. He changes his vote to -0. Dave, however, is convinced of the arguments and changes his vote to -1, with the suggestion to resolve this by explicitly writing down the missing interactions and feature combinations for RSM + * in separate documents to solve the problem "for now". With that, the ProtoXEP is vetoed (but see [1]). 6) Date of Next Everyone in for +1w. 7) AOB None. 8) Ite Meeting Est Thanks everyone. [1]: https://mail.jabber.org/pipermail/standards/2021-August/038490.html [2]: https://logs.xmpp.org/xsf/2021-08-09#2021-08-09-4407b454a06caebc ff signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Fwd: [Uta] STARTTLS vulnerabilities
Perhaps of interest here... Forwarded Message Subject: [Uta] STARTTLS vulnerabilities Date: Wed, 11 Aug 2021 17:42:40 +0200 From: Hanno Böck To: u...@ietf.org Hi, I wanted to share some research we have done on vulnerabilities in STARTTLS implementations: https://nostarttls.secvuln.info/ We started analyzing STARTTLS implementations in E-Mail servers and clients based on the 2011 command injection discovered in Postfix. We learned that this vulnerability is still very prevalent in current servers and that clients suffer from simliar vulnerabilities. We also found some IMAP specific vulnerabilities. Focussing on client-to-server communication our recommendations are mostly in line with what this working group has already concluded in RFC 8314, which is that implicit TLS on its own port should be preferred over STARTTLS. Our research has not focussed on the server-to-server part. Still I think particularly the buffering / injection vulnerabilities are a concern if one wants to secure s2s communication with mechanisms like MTA-STS. I strongly recommend that users of MTA-STS audit their STARTTLS implementations for buffering bugs. (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of the companies driving MTA-STS. I was unable to report this properly to Yahoo, I reported it through their Hackerone bugbounty program, but the bug triagers were unwilling to try to understand the issue and didn't forward it to Yahoo.) -- Hanno Böck https://hboeck.de/ ___ Uta mailing list u...@ietf.org https://www.ietf.org/mailman/listinfo/uta ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
tl;dr: its a mess. What is the deployment state of xep-0368? Am 11.08.21 um 19:08 schrieb Peter Saint-Andre: Perhaps of interest here... Forwarded Message Subject: [Uta] STARTTLS vulnerabilities Date: Wed, 11 Aug 2021 17:42:40 +0200 From: Hanno Böck To: u...@ietf.org Hi, I wanted to share some research we have done on vulnerabilities in STARTTLS implementations: https://nostarttls.secvuln.info/ We started analyzing STARTTLS implementations in E-Mail servers and clients based on the 2011 command injection discovered in Postfix. We learned that this vulnerability is still very prevalent in current servers and that clients suffer from simliar vulnerabilities. We also found some IMAP specific vulnerabilities. Focussing on client-to-server communication our recommendations are mostly in line with what this working group has already concluded in RFC 8314, which is that implicit TLS on its own port should be preferred over STARTTLS. Our research has not focussed on the server-to-server part. Still I think particularly the buffering / injection vulnerabilities are a concern if one wants to secure s2s communication with mechanisms like MTA-STS. I strongly recommend that users of MTA-STS audit their STARTTLS implementations for buffering bugs. (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of the companies driving MTA-STS. I was unable to report this properly to Yahoo, I reported it through their Hackerone bugbounty program, but the bug triagers were unwilling to try to understand the issue and didn't forward it to Yahoo.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
Too bad we didn't stick to our guns in 2003 and insist on two ports instead of one, but STARTTLS was the recommended approach back then... On 8/11/21 2:13 PM, Philipp Hancke wrote: > tl;dr: its a mess. What is the deployment state of xep-0368? > > Am 11.08.21 um 19:08 schrieb Peter Saint-Andre: >> Perhaps of interest here... >> >> >> Forwarded Message >> Subject: [Uta] STARTTLS vulnerabilities >> Date: Wed, 11 Aug 2021 17:42:40 +0200 >> From: Hanno Böck >> To: u...@ietf.org >> >> Hi, >> >> I wanted to share some research we have done on vulnerabilities in >> STARTTLS implementations: >> https://nostarttls.secvuln.info/ >> >> We started analyzing STARTTLS implementations in E-Mail servers and >> clients based on the 2011 command injection discovered in Postfix. We >> learned that this vulnerability is still very prevalent in current >> servers and that clients suffer from simliar vulnerabilities. We also >> found some IMAP specific vulnerabilities. >> >> Focussing on client-to-server communication our recommendations are >> mostly in line with what this working group has already concluded in >> RFC 8314, which is that implicit TLS on its own port should be >> preferred over STARTTLS. >> >> >> Our research has not focussed on the server-to-server part. Still I >> think particularly the buffering / injection vulnerabilities are >> a concern if one wants to secure s2s communication with mechanisms like >> MTA-STS. I strongly recommend that users of MTA-STS audit their >> STARTTLS implementations for buffering bugs. >> (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of >> the companies driving MTA-STS. I was unable to report this properly to >> Yahoo, I reported it through their Hackerone bugbounty program, but the >> bug triagers were unwilling to try to understand the issue and didn't >> forward it to Yahoo.) >> > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
In my experience it's widely supported these days. Out of the 119 providers on the jabber.at server list 74 of them (62%) have xmpps records (though I did not test whether these resulted in a successful connection with a reasonable TLS configuration). I also don't know if clients prioritize these records over starttls. —Sam On Wed, Aug 11, 2021, at 16:13, Philipp Hancke wrote: > tl;dr: its a mess. What is the deployment state of xep-0368? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: Too bad we didn't stick to our guns in 2003 and insist on two ports instead of one, but STARTTLS was the recommended approach back then... We were always at war with STARTTLS? -- Zash signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
On 8/11/21 3:35 PM, Kim Alvefur wrote: > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: >> Too bad we didn't stick to our guns in 2003 and insist on two ports >> instead of one, but STARTTLS was the recommended approach back then... > > We were always at war with STARTTLS? We would have preferred to keep using port 5223 for TLS-only, but at that time (2003/2004) IETF/IESG policy was "don't use so many ports, STARTTLS makes it so that you only need one". Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities
Am 11.08.21 um 23:49 schrieb Peter Saint-Andre: On 8/11/21 3:35 PM, Kim Alvefur wrote: On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: Too bad we didn't stick to our guns in 2003 and insist on two ports instead of one, but STARTTLS was the recommended approach back then... We were always at war with STARTTLS? We would have preferred to keep using port 5223 for TLS-only, but at that time (2003/2004) IETF/IESG policy was "don't use so many ports, STARTTLS makes it so that you only need one". ah, one port is enough. But I do wonder if the old technique from https://github.com/mawis/jabberd/blob/8c99ba9d56574044770c7513acd11c9072488203/jadc2s/clients.cc#L1289-L1301 (18 years...) is documented in some IETF document. There is https://datatracker.ietf.org/doc/html/rfc5764#section-5.1.2 but it only applies to DTLS. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
