14 Oct
2025
14 Oct
'25
9: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
9: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!
9: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
10: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
1:01 p.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
2:44 p.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
23 Oct
23 Oct
12:33 a.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
3 Nov
3 Nov
11:47 p.m.
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
4 Nov
4 Nov
10:06 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11:10 a.m.
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(a)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(a)xmpp.org
> To unsubscribe send an email to standards-leave(a)xmpp.org
11:19 a.m.
Thilo Molitor <thilo(a)eightysoft.de> writes:
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_Secur…
/Simon
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(a)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(a)xmpp.org
> To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5 Nov
5 Nov
5:32 p.m.
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
4 Nov
4 Nov
11:13 a.m.
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
5 Nov
5 Nov
5:07 p.m.
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(a)josefsson.org>
Sent: Tuesday, November 4, 2025 10:13 AM
To: Daniel Gultsch
Cc: standards(a)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
7
days inactive
29
days old
13 comments
6 participants
participants (6)
-
Daniel Gultsch -
Florian Schmaus -
Ludovic BOCQUET -
Matthew Wild -
Simon Josefsson -
Thilo Molitor