14 Oct
2025
14 Oct
'25
1:21 a.m.
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(a)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!
14 Oct
14 Oct
1:28 a.m.
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(a)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(a)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!
1:50 a.m.
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(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2:03 a.m.
On Tue, Oct 14, 2025 at 9:21 AM Daniel Gultsch <daniel(a)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
5:01 a.m.
On Tue, 14 Oct 2025 at 09:03, Daniel Gultsch <daniel(a)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
17 Oct
17 Oct
6:44 a.m.
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
22 Oct
22 Oct
4:33 p.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
0
days inactive
8
days old
6 comments
5 participants
participants (5)
-
Daniel Gultsch -
Florian Schmaus -
Matthew Wild -
Simon Josefsson -
Thilo Molitor