LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)
This message constitutes notice of a Last Call for comments on XEP-0440. Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. URL: https://xmpp.org/extensions/xep-0440.html This Last Call begins today and shall end at the close of business on 2025-10-28. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Editors note: There was a previous last call on in May 2024 in which a lot of people mentioned that the Security Considerations are currently lacking wrt what channel binding methods are recommended. The XEP has not been updated since. On Tue, Oct 14, 2025 at 9:21 AM Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0440.
Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on 2025-10-28.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
Hi I think it is time to require that the 'tls-exporter' channel binding is supported for compliant implementations. Yes, some may not be able to do it, but that is the true for all tightening of security bolts, and over time the software that can't follow security processes will gradually fade away... /Simon Daniel Gultsch <daniel@gultsch.de> writes:
This message constitutes notice of a Last Call for comments on XEP-0440.
Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on 2025-10-28.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, Oct 14, 2025 at 9:21 AM Daniel Gultsch <daniel@gultsch.de> wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Honestly I think we have been sitting on this XEP for so long that it has outlived it’s usefulness in many ways. In practice most implementations will just do tls-exporter over TLS1.3. Library support for that has been improved since this XEP was first proposed. tls-unique on the other hand has security issues and (AFAIK can not even be implemented on iOS for example) I‘m also reasonably sure that any deployment large enough to do TLS termination can figure out how to transfer the exporter bytes to the backend. Personally I see two ways forward. We scrap this XEP or we remove anything that recommends any binding mechanism over another. Basically we keep the XEP as a way to signal what binding mechanism the server supports and that’s it. cheers Daniel
On Tue, 14 Oct 2025 at 09:03, Daniel Gultsch <daniel@gultsch.de> wrote:
Personally I see two ways forward. We scrap this XEP or we remove anything that recommends any binding mechanism over another. Basically we keep the XEP as a way to signal what binding mechanism the server supports and that’s it.
I'm in favour of the latter. I know opinions vary (strongly) about whether 'tls-server-end-point' should be deployed by anyone ever, but for as long as there could be multiple channel binding methods (now or in the future) and we don't encode these in mechanism names (as SCRAM doesn't) then I think we should have a way for the server to advertise supported methods separately to SASL mechanisms, or we risk interoperability issues. Regards, Matthew
Hi Daniel, thanks for your feedback. On 14/10/2025 10.03, Daniel Gultsch wrote:
Personally I see two ways forward. We scrap this XEP or we remove anything that recommends any binding mechanism over another. Could you elaborate a bit on the rationale for removing anything that recommends any channel-binding mechanism over another?
Is it disputed that tls-exporter is superior than tls-sever-end-point? - Flow
Now to the last call itself:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, absolutely. With the various channel-binding types available today, it wouldn't be possible to negotiating the right one without this XEP.
2. Does the specification solve the problem stated in the introduction and requirements? Yes.
3. Do you plan to implement this specification in your code? If not, why not? Already done in Monal.
4. Do you have any security concerns related to this specification? No.
5. Is the specification accurate and clearly written? In my opinion, yes, but it could provide a little more clarity on why the MUST for tls-server-end-point is necessary.
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, with my editor hat on please note that a new version of this XEP has been published that should address some of the concerns. Also with my editor hat on I’m taking the liberty to extend the LC by another week to give people time to review the new version. With my council hat on I’m considering the endpoint v exporter concerns addressed. This is both due to the new Business rules that clearly outline the benefits of a common (minimum) binding mechanism and due to some discussions that happened in the kitten WG. The (somewhat related) discussion on Kitten revolved around deprecating endpoint in favor exporter at which multiple people spoke out against this. cheers Daniel
Thanks for the rewrite! While I still think this is a lost opportunity to mandate 'tls-exporter' for the XMPP eco-system, I think the new text is reasonable and does encourage use of 'tls-exporter'. This all still feels to me similar that we mandate DES or RC4 because there are some environments that doesn't implement AES. I think at some point, the reasonable reaction isn't to mandate DES/RC4 but to say "sorry, you really ought to change and use AES". But I also realize there are different view-points on this, and the text seems like a reasonable compromise. However, I suggest to drop 'or tls-unique' from this sentence: Tls-server-end-point was picked, because it is the lowest denominator that can be implemented by virtually everyone and even though it isn't as strong as tls-exporter or tls-unique, since tls-unique has known weaknesses: https://datatracker.ietf.org/doc/html/rfc9266#section-1 and doesn't work with TLS 1.3, so tls-unique requires TLS 1.2 which is generally less secure than TLS 1.3. Thus, I think that in some environments, even tls-server-end-point could be considered more secure than tls-unique. If people migrate away from tls-server-end-point, they should migrate to tls-exporter, and not consider tls-unique. I think the sentence gives the wrong impression regarding this. /Simon Daniel Gultsch <daniel@gultsch.de> writes:
Hi,
with my editor hat on please note that a new version of this XEP has been published that should address some of the concerns. Also with my editor hat on I’m taking the liberty to extend the LC by another week to give people time to review the new version.
With my council hat on I’m considering the endpoint v exporter concerns addressed. This is both due to the new Business rules that clearly outline the benefits of a common (minimum) binding mechanism and due to some discussions that happened in the kitten WG. The (somewhat related) discussion on Kitten revolved around deprecating endpoint in favor exporter at which multiple people spoke out against this.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Simon,
since tls-unique has known weaknesses: https://datatracker.ietf.org/doc/html/rfc9266#section-1 That might be true, but all reasonable implementations of TLS 1.2 nowadays use the extended master secret. For example OpenSSL 1.1.0 released in August 2016. So I'm inclined to consider this an issue fixed long ago.
and doesn't work with TLS 1.3, so tls-unique requires TLS 1.2 which is generally less secure than TLS 1.3. Where do you take that from? Afaik TLS 1.2 isn't less secure than TLS 1.3 (but a bit slower regarding connection establishment). But if you could provide some pointers, I would be happy to be corrected.
-tmolitor
Daniel Gultsch <daniel@gultsch.de> writes:
Hi,
with my editor hat on please note that a new version of this XEP has been published that should address some of the concerns. Also with my editor hat on I’m taking the liberty to extend the LC by another week to give people time to review the new version.
With my council hat on I’m considering the endpoint v exporter concerns addressed. This is both due to the new Business rules that clearly outline the benefits of a common (minimum) binding mechanism and due to some discussions that happened in the kitten WG. The (somewhat related) discussion on Kitten revolved around deprecating endpoint in favor exporter at which multiple people spoke out against this.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Thilo Molitor <thilo@eightysoft.de> writes:
and doesn't work with TLS 1.3, so tls-unique requires TLS 1.2 which is generally less secure than TLS 1.3. Where do you take that from? Afaik TLS 1.2 isn't less secure than TLS 1.3 (but a bit slower regarding connection establishment). But if you could provide some pointers, I would be happy to be corrected.
Granted, this isn't a binary "full security" or "no security" difference, but a balance, but still I would put up a red flag at anyone chosing TLS 1.2 while rejecting TLS 1.3. Some references: https://tolumichael.com/is-tls-1-2-deprecated-key-difference-from-tls-1-3/ https://software.land/tls-1.2-vulnerability/ https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Securi... /Simon
-tmolitor
Daniel Gultsch <daniel@gultsch.de> writes:
Hi,
with my editor hat on please note that a new version of this XEP has been published that should address some of the concerns. Also with my editor hat on I’m taking the liberty to extend the LC by another week to give people time to review the new version.
With my council hat on I’m considering the endpoint v exporter concerns addressed. This is both due to the new Business rules that clearly outline the benefits of a common (minimum) binding mechanism and due to some discussions that happened in the kitten WG. The (somewhat related) discussion on Kitten revolved around deprecating endpoint in favor exporter at which multiple people spoke out against this.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Granted, this isn't a binary "full security" or "no security" difference, but a balance, but still I would put up a red flag at anyone chosing TLS 1.2 while rejecting TLS 1.3. Some references:
https://tolumichael.com/is-tls-1-2-deprecated-key-difference-from-tls-1-3/ https://software.land/tls-1.2-vulnerability/ https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Securi ty#tls_1.3
Your references merely say that unsafe options like RSA key exchange (having no forward secrecy) etc. have been removed from TLS 1.3. This makes it more difficult to shoot yourself in the foot, which is good. But again, I'd argue that most modern XMPP servers and clients (at least those implementing XEP-0440) use TLS 1.2 with a reasonable configuration (e.g. more or less matching that of TLS 1.3). That said, somebody not wanting to implement TLS 1.3 but only 1.2 would indeed be a red flag. As far as TLS is concerned, version 1.3 is definitely the only sensible way forward. -tmolitor
Another comment: please hyperlink 'tls-exporter' with a reference to RFC 9266, for example in the final sentence of section 3. I think citing RFC 9266 is important to have a reference for the 'tls-exporter' specification and the security discussion in that document. /Simon
Dear all, Yes, it is important to specify a lot "tls-exporter", badly, a lot of projects do not support yet. It can be because a library of a project does not support. Some projects support: - nothing - "tls-unique" only - "tls-server-end-point" only - "tls-unique" and "tls-server-end-point" - "tls-unique" and "tls-exporter" - "tls-server-end-point" and "tls-exporter" (full compatibility with old and new systems) - "tls-unique" and "tls-server-end-point" and "tls-exporter" (full compatibility with old and new systems) - "tls-exporter" only (no compatible with old systems) The "tls-server-end-point" support permits a more easy migration from old systems to new systems before to be perfect with "tls-exporter" support. Regards, BOCQUET Ludovic ________________________________________ From: Simon Josefsson <simon@josefsson.org> Sent: Tuesday, November 4, 2025 10:13 AM To: Daniel Gultsch Cc: standards@xmpp.org Subject: [Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability) Another comment: please hyperlink 'tls-exporter' with a reference to RFC 9266, for example in the final sentence of section 3. I think citing RFC 9266 is important to have a reference for the 'tls-exporter' specification and the security discussion in that document. /Simon
participants (6)
-
Daniel Gultsch -
Florian Schmaus -
Ludovic BOCQUET -
Matthew Wild -
Simon Josefsson -
Thilo Molitor