Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
Old Thread Alert!! On Thu, 13 Feb 2020 at 04:33, Travis Burtrum wrote: > In practice, it doesn't matter, the server administrator can't actually > count on anyone accessing any of the SRV records in any specific order > because any network could have any types of blocks/constraints on it. > Therefore pending further comments here I'll submit a PR to propose > changing: > > > Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record > with regard to connection order as specified by RFC 2782 [3], in that > all priorities and weights are mixed. This enables the server operator > to decide if they would rather clients connect with STARTTLS or direct > TLS. However, clients MAY choose to prefer one type of connection over > the other. > > to something like this instead: > > > Both 'xmpp-' and 'xmpps-' records MAY be treated as the same record > with regard to connection order as specified by RFC 2782 [3], in that > all priorities and weights are mixed. Otherwise clients MAY choose to > prefer one type of connection over the other. > I propose: Both 'xmpp' and 'xmpps' records MAY be treated as the same record with regard to connection order as specified by RFC 2782 [3], in that all priorities and weights are mixed. However, initiating entities MAY choose to prefer Direct TLS, including by exhausting all 'xmpps' records prior to attempting any 'xmpp' records. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
Am Di., 11. Feb. 2020 um 16:31 Uhr schrieb Jonas Schäfer : > > The XEP Editor would like to Call for Experience with XEP-0368 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. Among the implementations that I control Conversations has implemented that. (Originally written by the author of the XEP) Also the Compliance Tester picks up on that. (Not sure if that counts :-) ) > 2. Have developers experienced any problems with the protocol as > defined in XEP-0368? If so, please describe the problems and, if > possible, suggested solutions. To set the ALPN I think the original implementation had to resort to reflections because Java 8 didn’t have a public interface for that. For the compliance tester I had to bump from Java 8 to Java 11 or so and to this date it's the only reason the compliance tester doesn’t run on Java 8. I don’t think it should stop the XEP from going forward though; but you asked… > > 3. Is the text of XEP-0368 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > If you have any comments about advancing XEP-0368 from Draft to Final, > please provide them by the close of business on 2020-02-25. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. I agree with what seems to be the consensus in the rest of the thread: The XEP should not mandate the mixing. (Even though Conversations does that) cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On 2/11/20 5:29 PM, Jonas Schäfer (XSF Editor) wrote: > The XEP Editor would like to Call for Experience with XEP-0368 before > presenting it to the Council for advancing it to Final status. > > You can review the specification here: > > https://xmpp.org/extensions/xep-0368.html > > Please send all feedback to the standards@xmpp.org discussion list. I am currently implementing direct TLS support in Smack. Since I decided to make this a optional "transport module" in Smack, mixing the 'xmpp' and 'xmpps' is not so trivial. I eventually decided to ignore this requirement. Especially since I could not come up with a good reason for it: If direct TLS is supported by the client and server, it appears to be the thing a client wants to try first. Irregardless of the SRV configuration. - Florian ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On Tue, 11 Feb 2020 at 16:30, Jonas Schäfer wrote: > The XEP Editor would like to Call for Experience with XEP-0368 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. > > Metre (MIT-licensed) has supported the majority of the specification over S2S for some time, but it does not follow the SHOULD of using ALPN - §3 point 7. Openfire (Apache-licensed) has supported listening for Direct TLS on both C2S and S2S for... ever? I believe it supports the SRV records now but I'll leave it to Guus to explain that. > 2. Have developers experienced any problems with the protocol as > defined in XEP-0368? If so, please describe the problems and, if > possible, suggested solutions. > > The SHOULD for ALPN does not seem to be widely implemented. I suspect that ALPN is more relevant for C2S than S2S in any case, but I think it's worthwhile to consider dropping this to a MAY given this is both rarely implemented and very rarely deployed. > 3. Is the text of XEP-0368 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > Aside from ALPN, as noted above, there is the question of mixing the xmpps/xmpp variants. I'm fine with this personally (Metre implements as specified), but I understand that some libraries find this difficult. I note that RFC 6186 uses a slightly different "mix", by selecting the protocol based on priority only (and then performing weight selection only within a protocol). Broadly, I am in favour of relaxing the mixing definition - I believe that initiators which favour direct TLS are fine (and even sensible), and initiators which choose to select both are entirely reasonable as well. > If you have any comments about advancing XEP-0368 from Draft to Final, > please provide them by the close of business on 2020-02-25. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. > > > You can review the specification here: > > https://xmpp.org/extensions/xep-0368.html > > Please send all feedback to the standards@xmpp.org discussion list. > ___ > 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] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On 2/11/20 11:29 AM, Jonas Schäfer (XSF Editor) wrote: > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. Conversations and Dino both implement this as well. > 2. Have developers experienced any problems with the protocol as > defined in XEP-0368? If so, please describe the problems and, if > possible, suggested solutions > 3. Is the text of XEP-0368 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. It seems many implementations have problems (library constraints) or choose not to (simplicity) support the mixing behavior. Conversations is the only implementation I know of off the top of my head that does implement it, I wrote that implementation before this XEP existed, originally had it as a MUST, ended up changing it to a SHOULD, and now it seems likely it should be changed to a MAY. In practice, it doesn't matter, the server administrator can't actually count on anyone accessing any of the SRV records in any specific order because any network could have any types of blocks/constraints on it. Therefore pending further comments here I'll submit a PR to propose changing: > Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record with regard to connection order as specified by RFC 2782 [3], in that all priorities and weights are mixed. This enables the server operator to decide if they would rather clients connect with STARTTLS or direct TLS. However, clients MAY choose to prefer one type of connection over the other. to something like this instead: > Both 'xmpp-' and 'xmpps-' records MAY be treated as the same record with regard to connection order as specified by RFC 2782 [3], in that all priorities and weights are mixed. Otherwise clients MAY choose to prefer one type of connection over the other. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On Tue, Feb 11, 2020, at 11:29, Jonas Schäfer wrote: > 1. What software has XEP-0368 implemented? I have implemented this in my XMPP library which is used by several small clients, bots, and notification services. The documentation for the relevant package (and links to the source) can be found at: https://pkg.go.dev/mellium.im/xmpp/dial > 2. Have developers experienced any problems with the protocol as >defined in XEP-0368? If so, please describe the problems and, if >possible, suggested solutions. I have experienced the same problems Philipp mentioned and am ignoring these parts of the spec. Because of this, I think the SRV record mixing needs to be fixed before this specification is allowed to move forward. > 3. Is the text of XEP-0368 clear and unambiguous? In the glossary definition for "Direct TLS" the definition is oddly phrased. "like how HTTPs works" both sounds odd to me grammatically, and it is unclear what it means unless you understand HTTPS which may or may not be a reasonable assumption. I think this entire definition needs to be rewritten. In section 5, "Implementation Notes", ALPN is referenced several times but it is not expanded anywhere that I see; maybe the acronym should be expanded on first use? There is a link to the RFC, I'm not sure if that's good enough though since XEPs may be printed. In section 5, "Implementation Notes", a sentence ends "disabled by a user due to privacy reasons". The phrase "due to privacy reasons" sounds odd to me, but I couldn't say why. It's probably not worth having it there, "it may be disabled by a user" is good enough. DNSSEC is mentioned in the security considerations but it's not linked and the acronym is never expanded. In section 7, "IANA Considerations", the ALPN RFC is linked again. I'm not sure if this is a problem or not, it just feels weird that the RFC is linked in several sections but not in others. I'd just link to it on first mention of ALPN. This is a very minor nit pick though. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On Tue, Feb 11, 2020, at 11:43, Philipp Hörist wrote: > Mixing DIRECT and START TLS is problematic i guess its not supported > by any library that offers some kind of abstraction over sockets. > > … > > This rule will most likely be ignored by clients. I have run into this problem and would like to confirm that in my implementation I am ignoring this rule because it makes the implementation much more complicated and doesn't provide any real benefit that I can see, just confusion. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
On Dienstag, 11. Februar 2020 17:29:47 CET Jonas Schäfer wrote: > The XEP Editor would like to Call for Experience with XEP-0368 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. aioxmpp (LGPLv3) has an implementation [1]. This implementation was created by me and independently. > 2. Have developers experienced any problems with the protocol as > defined in XEP-0368? Yes. The specification describes a new SRV record service label. The problem is with the interaction of the various cases which can be expressed with SRV records for xmpp-client and xmpps-client on the same domain (the same goes for xmpp/s-server, but for simplicity, I’ll write my notes with *-client only). First, a recap of what RFC 6120 says (abridged from Section 3.2 [2]): 1. Check if there is a _xmpp-client record for the domain. If there is: 1.1. If it points to the host ., stop connecting and inform user that the domain does not offer XMPP. 1.2. Use normal SRV logic to pick connection targets otherwise, continue: 2. Look up A/ records for the domain. Try to connect to the IP addresses as found on port 5222 with STARTTLS. XEP-0368 now brings _xmpps-client records into the mix. As currently written, XEP-0368 specifies that if both record types are present, the targets are mixed. So for example, on a domain with the following records: _xmpp-client._tcp IN SRV 1 1 5222 xmpp.domain.example. _xmpps-client._tcp IN SRV 1 1 5223 xmpp.domain.example. there would be a fifty-fifty chance as to whether the client uses STARTTLS or Direct TLS (assuming the client does not hard-code a preference). This case is rather clear, although a non-standard use of SRV records. However, the following cases need to be thought of and clearly defined in the document to be compatible with RFC 6120: - _xmpp-client set to `.`, _xmpps-client has valid entries - _xmpps-client set to `.`, _xmpp-client has valid entries - Neither are present (the only RFC 6120-compatible way here is to fall back to STARTTLS on A/ port 5222) - _xmpp-client has no records, _xmpps-client has valid entries (and the opposite case; I think those are implicitly covered by the mixing rules) I think the community needs to agree on what the correct behaviour is. We also probably should have the discussion on whether the mixing of the records is definitely and Final-ly okay. I know of at least one implementation which refuses to do the mixing [3]. In case we drop the mixing, we need clear guidelines for operators to inform them of the implications. Specifically, this may make clients attempt Direct TLS on all SRV tiers (priorities) first and then fall back to (forced) STARTTLS; this needs to be written down in the document, since it may have unintended side effects if only a subset of the nodes of the tiers support Direct TLS. > 3. Is the text of XEP-0368 clear and unambiguous? Except for the points above. > Are more examples needed? Would be good once we define the rules to the cases I mentioned above. > Is the conformance language (MAY/SHOULD/MUST) appropriate? I think so. > Have developers found the text confusing at all? Not confusing per se, but there certainly have been disagreements (see above). > Please describe any suggestions you have for improving the text. > > If you have any comments about advancing XEP-0368 from Draft to Final, > please provide them by the close of business on 2020-02-25. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. > > > You can review the specification here: > > https://xmpp.org/extensions/xep-0368.html > > Please send all feedback to the standards@xmpp.org discussion list. [1]: https://github.com/horazont/aioxmpp/blob/ 9d93b63b12f39478cfab1c46f09d274230ccf081/aioxmpp/node.py#L167 [2]: https://tools.ietf.org/html/rfc6120#section-3.2 [3]: https://github.com/mellium/xmpp/ 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 ___
Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
> > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. > Gajim / nbxmpp > > 2. Have developers experienced any problems with the protocol as > defined in XEP-0368? If so, please describe the problems and, if > possible, suggested solutions. > Mixing DIRECT and START TLS is problematic i guess its not supported by any library that offers some kind of abstraction over sockets. For example in GLib you can connect to a SRV record, GLib resolves the SRV record mixes it and does happy eyeballs to connect to the address. If i have to mix i cant use this, i have to write my own resolver code, i have to wait on 2 SRV records to finish, and have to mix myself. Its unreasonable to ask libs to implement such a behavior, seems quite unique to mix different SRV records. The benefit is not really clear, Applications would want to favor Direct TLS its less roundtrips. We are treating something the same which is not the same. And one has a clear benefit. This rule will most likely be ignored by clients. > 3. Is the text of XEP-0368 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > Remove the mixing of SRV records Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
The XEP Editor would like to Call for Experience with XEP-0368 before presenting it to the Council for advancing it to Final status. During the Call for Experience, please answer the following questions: 1. What software has XEP-0368 implemented? Please note that the protocol must be implemented in at least two separate codebases (at least one of which must be free or open-source software) in order to advance from Draft to Final. 2. Have developers experienced any problems with the protocol as defined in XEP-0368? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0368 clear and unambiguous? Are more examples needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments about advancing XEP-0368 from Draft to Final, please provide them by the close of business on 2020-02-25. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the specification here: https://xmpp.org/extensions/xep-0368.html Please send all feedback to the standards@xmpp.org discussion list. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
