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 2024-05-20. 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!
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, it allows to negotiate the used channel-binding rather than just guessing what type the server might support.
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 implemented for > 1 year now
4. Do you have any security concerns related to this specification? No
5. Is the specification accurate and clearly written? Yes
-tmolitor
Hi all, On 5/6/24 1:21 PM, Daniel Gultsch wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No. And in fact it opens gaps.
2. Does the specification solve the problem stated in the introduction and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with the MITM themselves.
3. Do you plan to implement this specification in your code? If not, why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes. This specification? No.
4. Do you have any security concerns related to this specification?
So many. 1. it gives a MUST for servers and SHOULD for clients to implement tls-server-end-point which is weak and likely shouldn't be implemented at all. Note TLS-intercepting-proxies can implement the strong tls-exporter just fine by simply passing the keying material to the backend server. See https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA3... for more discussion. 2. tls-unique is broken by https://www.mitls.org/pages/attacks/3SHAKE and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your client-side TLS library and config meets a ton of ifs. It has to implement the extended master secret extension *and* the server has to negotiate this. (remember, the server here is the potential attacker, so it would just... not). So to securely implement tls-unique a client would need to *require* negotiation of the extended master secret extension for TLS 1.2 connections and fail to connect otherwise. How many clients do this? How many clients have any idea whether their TLS lib supports or enforces this? How many TLS libs even let you check this? We must assume tls-unique is not to be trusted. 3. That leaves tls-exporter as the only secure channel binding method. One method doesn't need negotiation. A wise person recently said "parameterize of security protocols and algorithms are generally a bad idea as it adds complexity which reduces security." https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4H... This spec in particular says to nicely ask the attacker if they support it before doing it... and the attacker will just say no. The XEP handwaves this security destroying attack as a "well clients could pin channel bindings" not even a MAY, SHOULD, or MUST. Do any implementations today do this? If not it is just feel good security theater that gives absolutely no security against a MITM.
5. Is the specification accurate and clearly written?
See #4 In summary, a XEP to negotiate channel binding with the attacker isn't helpful. The only security we can get from channel binding is by *requiring* clients to do only tls-exporter with only TLS 1.3 or QUIC. If this fails the client MUST pop up a warning similar to "this is an untrusted certificate, deny/allow". If we want a XEP that suggests the above it should be clear in the security considerations what it prevents and what it doesn't, and how it compares to other things like public key pinning (DANE or '487), likely suggesting to do both. Roughly both public key pinning and requiring tls-exporter channel binding both protect against a jabber.ru style MITM where the MITM gets their own new certificate, but does not read the disk of the server they are attacking. Neither public key pinning *nor* channel binding protect against a MITM where the attacker can read the disk of the XMPP server and take the public key (and/or cert) and password hashes to use for SCRAM authentication itself. Thanks, Travis
Turns out tls-unique is *additionally* broken by https://www.mitls.org/pages/attacks/SLOTH found a few months after the release of RFC7627 that tried to fix it:
If your TLS application relies on the tls-unique channel binding to prevent credential forwarding, you need to redesign your application. Our attack on the tls-unique channel binding affects application-level protocols that rely on this channel binding to prevent credential forwarding attacks. In general, all uses of tls-unique are suspect, but the following are known to be specifically affected: * SCRAM is used in SASL and GSSAPI and relies on tls-unique for channel binding. SCRAM is the default authentication protocol for XMPP.
Hi Travis, While I agree with most of your assessment in general, there is a few things that need to be corrected: Key pinning using '487 would not have prevented the jabber.ru attack, as it is already known that the attacker was able to intercept and handle http(s) requests themselves, so they would also be able to manipulate the host-meta file and thereby pin to a new public key that they control. In this context it's worth noting that SCRAM channel binding (even if broken) is never worse than key pinning over HTTPS, as HTTPS doesn't provide similar security. The only thing that '487 could do is to delay the start of the attack by up to '487's TTL. Similar reasoning can be applied to DANE, although it's less obvious that the jabber.ru attacker would be able to manipulate the DNS. However given that the jabber.ru attacker seemingly was able to manipulate the network of two different hosting companies, it's reasonable to assume they'd be able to manipulate a domain registrar and/or hosted DNS service as needed. SLOTH severely weakens the security of tls-unique SCRAM, however due to it still requiring up to 2^48 HMAC computations, a practical attack is very unlikely and requires much larger resources than used in the jabber.ru attack (remember the 2^48 HMACs must be calculated within a minute or so as the connection would timeout if not). I'd therefore conclude that a widespread deployment of 0440 and 0474 would likely have prevented the jabber.ru attack even if tls-exporter was not provided. <hr> Most notable though, regarding your feedback, it makes it sound as if 0440 was unfixable, however I think your feedback could be well incorporated into 0440 to resolve your valid concerns. To address your concerns I'd suggest the following changes to 0440: - Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility. - Add tls-exporter as a SHOULD for servers and clients, specifically mentioning it's what should be used if technically possible - Add that clients SHOULD pin channel binding methods (in a way that allows upgrades to tls-exporter but not downgrades from it) OR use other reasonable methods to prevent downgrades, e.g. by using 0474. Beside that, I think your understanding of the wording "gaps in the XMPP protocol" is (intentionally) wrong: Without 0440 there is no way to discover which channel binding types can be used, with 0440 there is one. The question thus is if the lack of discoverability is a "gap" in the protocol and I think it clearly is, with your answer you claim it's not, that is, you claim there is no need for discoverability of channel binding capability. All the problems that you describe are not related to the protocol, but to the protocols that can be announced with it and the advice from the XEP's Security Considerations. Most notably, the protocol does not prevent clients from completely ignoring it and always trying to use tls-exporter even if not in the list, which would just be the status without 0440. As such 0440 is a strict improvement over the status quo, even if not perfect. Marvin On Tue, 2024-05-07 at 21:34 -0400, Travis Burtrum wrote:
Hi all,
On 5/6/24 1:21 PM, Daniel Gultsch wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No. And in fact it opens gaps.
2. Does the specification solve the problem stated in the introduction and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with the MITM themselves.
3. Do you plan to implement this specification in your code? If not, why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes. This specification? No.
4. Do you have any security concerns related to this specification?
So many.
1. it gives a MUST for servers and SHOULD for clients to implement tls-server-end-point which is weak and likely shouldn't be implemented at all. Note TLS-intercepting-proxies can implement the strong tls-exporter just fine by simply passing the keying material to the backend server. See https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA3... for more discussion.
2. tls-unique is broken by https://www.mitls.org/pages/attacks/3SHAKE and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your client-side TLS library and config meets a ton of ifs. It has to implement the extended master secret extension *and* the server has to negotiate this. (remember, the server here is the potential attacker, so it would just... not).
So to securely implement tls-unique a client would need to *require* negotiation of the extended master secret extension for TLS 1.2 connections and fail to connect otherwise. How many clients do this? How many clients have any idea whether their TLS lib supports or enforces this? How many TLS libs even let you check this?
We must assume tls-unique is not to be trusted.
3. That leaves tls-exporter as the only secure channel binding method.
One method doesn't need negotiation. A wise person recently said "parameterize of security protocols and algorithms are generally a bad idea as it adds complexity which reduces security." https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4H...
This spec in particular says to nicely ask the attacker if they support it before doing it... and the attacker will just say no. The XEP handwaves this security destroying attack as a "well clients could pin channel bindings" not even a MAY, SHOULD, or MUST. Do any implementations today do this? If not it is just feel good security theater that gives absolutely no security against a MITM.
5. Is the specification accurate and clearly written?
See #4
In summary, a XEP to negotiate channel binding with the attacker isn't helpful.
The only security we can get from channel binding is by *requiring* clients to do only tls-exporter with only TLS 1.3 or QUIC. If this fails the client MUST pop up a warning similar to "this is an untrusted certificate, deny/allow".
If we want a XEP that suggests the above it should be clear in the security considerations what it prevents and what it doesn't, and how it compares to other things like public key pinning (DANE or '487), likely suggesting to do both. Roughly both public key pinning and requiring tls-exporter channel binding both protect against a jabber.ru style MITM where the MITM gets their own new certificate, but does not read the disk of the server they are attacking. Neither public key pinning *nor* channel binding protect against a MITM where the attacker can read the disk of the XMPP server and take the public key (and/or cert) and password hashes to use for SCRAM authentication itself.
Thanks, Travis _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, I think most of use can agree that TLS1.3 and tls-exporter is where we want to end up at. I will likely modify the 'Require Channel Binding' setting in Conversations to require that specific channel binding instead of just any. However on the path toward that goal and to provide good error messages in case client side requirements with regards to channel binding are not met we need negotiation. Furthermore I believe that even the weaker channel binding mechanisms are better than not having them. It puts more hurdles into the attackers way. Attackers aren’t always perfect. In the case of jabber.ru it looked a lot like they were throwing vanilla proxy software at the problem and not something specifically tailored to break XMPP. The other 'not really an attack' attack that even weak channel binding can detect is when people for what ever reason install custom CA certificates on the phone. I agree that the current phrasing of the XEP with regards to server-end-point is not the best. cheers Daniel
On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440:
- Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility.
I'd like to note that we previously explicitly decided[1] that requiring a common channel-binding type would increase security. And that type had to be tls-server-end-point, as it is generally available. That is why the XEP currently says that servers MUST support tls-server-end-point.
- Add tls-exporter as a SHOULD for servers and clients, specifically mentioning it's what should be used if technically possible - Add that clients SHOULD pin channel binding methods (in a way that allows upgrades to tls-exporter but not downgrades from it) OR use other reasonable methods to prevent downgrades, e.g. by using 0474.
Those two points are valid, the XEP already tries to encourage usage of tls-exporter (although the wording could be improved) and suggests pinning to improve security. However, using RFC keywords in such cases was sometimes met with little approval in the past. That is the main reason why the XEP does avoid it at the moment. If it is consensus that using RFC keywords here provides a significant advantage, then it can be changed. That said, I am a little bit unhappy with "SHOULD pin channel binding methods or use other reasonable methods". Personally, I would avoid the combination of a SHOULD/MUST with some rather imprecise requirements ("other reasonable methods"). - Flow 1: See Russlan's standards@ mail from 2020-07-01
On 08/05/2024 16.42, Florian Schmaus wrote:
On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440:
- Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility.
I'd like to note that we previously explicitly decided[1] that requiring a common channel-binding type would increase security. And that type had to be tls-server-end-point, as it is generally available. That is why the XEP currently says that servers MUST support tls-server-end-point.
And now I also have the link to the thread with the motivation that there should be at least one common cb type: https://web.archive.org/web/20221129011623/https://mail.jabber.org/pipermail... (Thanks to travis for pointing out that the old ML archives are still available via archive.org) Note that a probably relevant remark from Dave is that mandatory-to-implement does not automatically imply mandatory-to-deploy. :) - Flow
Hi, I didn't want to suggest specific wording, but the more I think about it, the more I am against of any RFC style wording in the Security Considerations section of 0440. If it's part of the protocol described in 0440 and RFC style wording makes sense, it should be outside the Security Considerations (it maybe repeated there for emphasis). If it's not part of the protocol of 0440, then it shouldn't be using RFC style wording in first place. Many Security Considerations (especially those related to the security of channel binding types) apply no matter if 0440 is implemented, so why would be put anything normative about their security in 0440? The whole "Which channel-binding types should be supported?" IMO belongs somewhere else, not in 0440. Security Considerations can provide some guidance here (and also some rationale as to why it might be reasonable to implement tls-server-end-point even if tls-exporter is more secure), but those shouldn't be normative in any capacity. Marvin On Wed, 2024-05-08 at 16:42 +0200, Florian Schmaus wrote:
On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440:
- Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility.
I'd like to note that we previously explicitly decided[1] that requiring a common channel-binding type would increase security. And that type had to be tls-server-end-point, as it is generally available. That is why the XEP currently says that servers MUST support tls-server-end- point.
- Add tls-exporter as a SHOULD for servers and clients, specifically mentioning it's what should be used if technically possible - Add that clients SHOULD pin channel binding methods (in a way that allows upgrades to tls-exporter but not downgrades from it) OR use other reasonable methods to prevent downgrades, e.g. by using 0474.
Those two points are valid, the XEP already tries to encourage usage of tls-exporter (although the wording could be improved) and suggests pinning to improve security.
However, using RFC keywords in such cases was sometimes met with little approval in the past. That is the main reason why the XEP does avoid it at the moment.
If it is consensus that using RFC keywords here provides a significant advantage, then it can be changed.
That said, I am a little bit unhappy with "SHOULD pin channel binding methods or use other reasonable methods". Personally, I would avoid the combination of a SHOULD/MUST with some rather imprecise requirements ("other reasonable methods").
- Flow
1: See Russlan's standards@ mail from 2020-07-01
I want to bump this email from an earlier LC of 0440 On Wed, May 8, 2024 at 5:16 PM Marvin W <xmpp@larma.de> wrote:
I didn't want to suggest specific wording, but the more I think about it, the more I am against of any RFC style wording in the Security Considerations section of 0440. If it's part of the protocol described in 0440 and RFC style wording makes sense, it should be outside the Security Considerations (it maybe repeated there for emphasis). If it's not part of the protocol of 0440, then it shouldn't be using RFC style wording in first place. Many Security Considerations (especially those related to the security of channel binding types) apply no matter if 0440 is implemented, so why would be put anything normative about their security in 0440?
The whole "Which channel-binding types should be supported?" IMO belongs somewhere else, not in 0440. Security Considerations can provide some guidance here (and also some rationale as to why it might be reasonable to implement tls-server-end-point even if tls-exporter is more secure), but those shouldn't be normative in any capacity.
Yes. Basically this. ^ I did a little bit of digging and it seems that the making endpoint a MUST got introduced by Thilo presumably because iOS doesn’t do unique. However that was 5 years ago and while that is still true we live in a TLS 1.3 world now and export seems to be fairly widely supported. Again I’m not saying that the XEP should explicitly recommend against endpoint but also not require it (neither as MUST nor as SHOULD (it was should prior to Thilo‘s change)) So yeah, basically what Marvin said 1.5 years ago. cheers Daniel
On Sat, 18 Oct 2025 at 17:32, Daniel Gultsch <daniel@gultsch.de> wrote:
I want to bump this email from an earlier LC of 0440
On Wed, May 8, 2024 at 5:16 PM Marvin W <xmpp@larma.de> wrote:
I didn't want to suggest specific wording, but the more I think about it, the more I am against of any RFC style wording in the Security Considerations section of 0440. If it's part of the protocol described in 0440 and RFC style wording makes sense, it should be outside the Security Considerations (it maybe repeated there for emphasis). If it's not part of the protocol of 0440, then it shouldn't be using RFC style wording in first place. Many Security Considerations (especially those related to the security of channel binding types) apply no matter if 0440 is implemented, so why would be put anything normative about their security in 0440?
The whole "Which channel-binding types should be supported?" IMO belongs somewhere else, not in 0440. Security Considerations can provide some guidance here (and also some rationale as to why it might be reasonable to implement tls-server-end-point even if tls-exporter is more secure), but those shouldn't be normative in any capacity.
Yes. Basically this. ^
FWIW, I've argued for decades that MTI levels and protocols ought not to be combined in a single specification. But anyway. Yes, the MTI advice in this document is indeed a bit weird. tls-server-endpoint is MUST, but with little background information, but it then goes on to say that tls-exporter is preferable.
I did a little bit of digging and it seems that the making endpoint a MUST got introduced by Thilo presumably because iOS doesn’t do unique. However that was 5 years ago and while that is still true we live in a TLS 1.3 world now and export seems to be fairly widely supported.
Again I’m not saying that the XEP should explicitly recommend against endpoint but also not require it (neither as MUST nor as SHOULD (it was should prior to Thilo‘s change))
Stock Java still doesn't support tls-exporter. You can use Bouncy Castle, though (and even unto FIPS), and get access - if local policy allows, which it might not. Otherwise you're stuck with tls-server-endpoint - which is still better than nothing of course. The web browser doesn't support anything useful at all, you're entirely out for channel binding - and therefore may wish to support "non channel binding" versions. Any server operating behind a load balancer that terminates TLS cannot do anything but tls-server-endpoint, of course. At minimum, I think a document, somewhere, should provide advice on what security stuff to implement and why in 2025, and include the MTIs for such things, and be kept current. That could I suppose be the compliance docs, though those have typically concentrated on features rather than security MTIs. At the moment that seems to be this document for channel bindings, which is not ideal, I agree. (If nobody else fancies writing a separate document, I'd be up for making a start on one?)
So yeah, basically what Marvin said 1.5 years ago.
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On 10/20/25 4:46 AM, Dave Cridland wrote:
At minimum, I think a document, somewhere, should provide advice on what security stuff to implement and why in 2025, and include the MTIs for such things, and be kept current.
It sounds like we need a replacement for RFC 7590, which was published in June 2015. The IETF's UTA WG is still operational, so the work could happen there; alternatively, we could publish a XEP (easier to update), although we might want to coordinate with the UTA WG chairs to at least inform them of the effort at the XSF. Peter
On Mon, 20 Oct 2025 at 14:55, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 10/20/25 4:46 AM, Dave Cridland wrote:
At minimum, I think a document, somewhere, should provide advice on what security stuff to implement and why in 2025, and include the MTIs for such things, and be kept current.
It sounds like we need a replacement for RFC 7590, which was published in June 2015. The IETF's UTA WG is still operational, so the work could happen there; alternatively, we could publish a XEP (easier to update), although we might want to coordinate with the UTA WG chairs to at least inform them of the effort at the XSF.
I'll take "RFCs I have forgotten about" for 400, Peter. But yes, that one, but with SASL and Channel Bindings and such things. Dave.
On 10/20/25 9:58 AM, Dave Cridland wrote:
On Mon, 20 Oct 2025 at 14:55, Peter Saint-Andre <stpeter@stpeter.im <mailto:stpeter@stpeter.im>> wrote:
On 10/20/25 4:46 AM, Dave Cridland wrote:
> At minimum, I think a document, somewhere, should provide advice on what > security stuff to implement and why in 2025, and include the MTIs for > such things, and be kept current.
It sounds like we need a replacement for RFC 7590, which was published in June 2015. The IETF's UTA WG is still operational, so the work could happen there; alternatively, we could publish a XEP (easier to update), although we might want to coordinate with the UTA WG chairs to at least inform them of the effort at the XSF.
I'll take "RFCs I have forgotten about" for 400, Peter.
But yes, that one, but with SASL and Channel Bindings and such things.
Perhaps the Council can discuss this in its next meeting. I can help coordinate with the UTA WG Chairs and, if we decide to work on this at the IETF, co-author the document with someone who has more knowledge of the state of play in XMPP implementations than I do. Peter
On Mon, Oct 20, 2025 at 12:47 PM Dave Cridland <dave@cridland.net> wrote:
Stock Java still doesn't support tls-exporter. You can use Bouncy Castle, though (and even unto FIPS), and get access - if local policy allows, which it might not. Otherwise you're stuck with tls-server-endpoint - which is still better than nothing of course.
I’m reading this as an argument on why this XEP should exits (Allowing the server to announce what channel binding features it supports), rather then an argument that the security considerations should keep requiring endpoint.
The web browser doesn't support anything useful at all, you're entirely out for channel binding - and therefore may wish to support "non channel binding" versions.
FWIW WebTransport is close to ready and has exporter support.
Any server operating behind a load balancer that terminates TLS cannot do anything but tls-server-endpoint, of course.
Someone apparently has a prototype that transmits the exporter bytes from the TLS termination proxy to the XMPP server via proxy protocol... But yes, giving people the option to do endpoint is certainly desired.
I am going to reply to Dave's post in an attempt to get the discussion back on track. Because, right now, it got a bit derailed by the assumption that XEP-0440 requires tls-server-endpoint just for the sake of it (at least, that is my impression). On 20/10/2025 12.46, Dave Cridland wrote:
Yes, the MTI advice in this document is indeed a bit weird. tls-server- endpoint is MUST, but with little background information,
Actually the rationale for doing so is provided in the beginning of the "Security Considerations" section (right before the tls-server-endpoint requirement is stated). IIRC ca. 2022 Thilo (in CC) made a case that a mutual shared cb-type improves the security. And the lowest common denominator simply is tls-server-endpoint, which is what we want servers to support and annouce to achieve the goal of a mutual shared cb-type. If a am not mistaken, this was also discussed on the standard@ mailing list. Reading the current last call discussion, I don't get the impression that this previous discussion and the provided arguments are taken into account. Don't get me wrong. I do not plan to object whatever decision we are going to make. But those who want to change the XEP (again) should explain why the arguments back then are not, or no longer, valid.
but it then goes on to say that tls-exporter is preferable.
It is preferable, isn't it? - Flow
As far as I understood the argument back then was: We need to support a widely supported mechanism because 'weak' channel binding is better than no channel binding. This still holds true and is also kinda self evident. What has changed in the 5 years since we discussed this is a perception of what that mechanism should be. The alternative to forever enshrining 'endpoint' as a MUST would simply be to discuss - in non normative language - the trade off between supporting something very widely implementable like endpoint and something like exporter.
What has changed in the 5 years since we discussed this is a perception of what that mechanism should be.
The alternative to forever enshrining 'endpoint' as a MUST would simply be to discuss - in non normative language - the trade off between supporting something very widely implementable like endpoint and something like exporter.
No, that won't work. It *must* be something every client and server implementing channel-binding would be able to implement *and* offer/use. And as of today I don't know of any other channel-binding that can be used everywhere (even when using load-balancers etc). In general, I think we should create security for today, not for a hypothetical future. We can always update/depreciate this MUST via a new XEP if there ever emerges a channel binding type with the same ubiquitous properties. -tmolitor
Sorry for not chiming in earlier. I've been very busy lately. Channel-binding in the xmpp-ecosystem is currently only widely deployed through SCRAM (even though some PAKE mechanism could be used with channel- binding, too). So I will only cover the SCRAM case here. In SCRAM (RFC 5802) the client-first-message contains 3 possible values in the GSS-header part: 1. y - The client would have used channel-binding, but the server did not offer any. 2. n - The client does not support channel-binding (even if the server offered any). 3. p=<cb-name> - The name of the channel-binding, the client wants to use. The RFC explains, that sending "y" when the server advertised channel-binding support is to be used as a MITM-detection: An attacker stripping out all *-PLUS variants can be detected this way (the server knows it advertised them and the client says via "y", that it would have used them if it saw them, so the server can abort the authentication in this case). This works reasonably well, if there is only one single channel-binding possible. But that's the exact assumption this XEP is going to change: it is possible to advertise a list of different channel-bindings for the client to choose. That's good for protocol agility, something that's important enough to have algorithm negotiation in TLS, for example. I think we all can agree here, that protocol agility is important and so this XEP is needed. So now we have a problem: what to do if the server advertised a list of channel-binding algorithms, but the client doesn't support any of these? In the non-attacker case, the client can't send "y" in the GSS-header, because the server would then abort the authentication because it advertised channel- bindings. But sending "n" and continuing without channel-binding is fine in this case. This isn't fully hypothetical. An older client might only support tls-unique, while the server only advertises tls-exporter (which can be used for tls 1.2, too, if the extended master secret is used). Blocking the connection entirely is of course at the discretion of the client developer, but it hinders interoperability, especially while phasing out one channel-binding-type and introducing a new one. Now the attacker case: Any MITM-attacker could just manipulate the list of channel-bindings advertised using this XEP to just list some dummy mechanisms (or mechanisms they know the client doesn't support). That would successfully downgrade the client to non-channel-binding, if the client still sent "n" as above. The client won't be able to distinguish the attacker case from the non- attacker one. How to fix this while not hindering interoperability? Implementing XEP-0474 is one option (and an even better one). But for defence-in-depth and to support cases when this isn't possible (for example when the SCRAM library used doesn't support adding optional attributes), a few years back I proposed to add a countermeasure to this XEP (the part we are discussing in this thread): Having a MUST to implement and advertise tls-server-end-point when advertising channel-binding types using this XEP. Tls-server-end-point 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, it still catches many attacks (it would have detected the jabber.ru one, for example). Now with this MUST in place, a client seeing a list without tls-sever-end- point advertised, immediately knows, that some attacker tampered with the list of channel-bindings and can abort the authentication. It never needs to send "n" even though it supports channel-binding and can still safely send "y" if it doesn't see any *-PLUS variants and channel-bindings announced. (Short note: making this a SHOULD or MAY contradicts this, it has to be a MUST here.) Note: I do not have any objection to move that MUST into another section of the XEP if you think, that the Security Considerations section is the wrong place for this. And I equally don't object adding more explanation why this MUST is necessary to the XEP as well. Additional note: no, I completely disagree with Daniel's opinion that we will eventually be able to have channel binding enabled by default at all times for the same reasons Holger has, but that's off-topic. -tmolitor Am Mittwoch, 22. Oktober 2025, 13:29:38 CEST schrieb Florian Schmaus:
I am going to reply to Dave's post in an attempt to get the discussion back on track. Because, right now, it got a bit derailed by the assumption that XEP-0440 requires tls-server-endpoint just for the sake of it (at least, that is my impression).
On 20/10/2025 12.46, Dave Cridland wrote:
Yes, the MTI advice in this document is indeed a bit weird. tls-server- endpoint is MUST, but with little background information,
Actually the rationale for doing so is provided in the beginning of the "Security Considerations" section (right before the tls-server-endpoint requirement is stated).
IIRC ca. 2022 Thilo (in CC) made a case that a mutual shared cb-type improves the security. And the lowest common denominator simply is tls-server-endpoint, which is what we want servers to support and annouce to achieve the goal of a mutual shared cb-type. If a am not mistaken, this was also discussed on the standard@ mailing list.
Reading the current last call discussion, I don't get the impression that this previous discussion and the provided arguments are taken into account.
Don't get me wrong. I do not plan to object whatever decision we are going to make. But those who want to change the XEP (again) should explain why the arguments back then are not, or no longer, valid.
but it then goes on to say that tls-exporter is preferable.
It is preferable, isn't it?
- Flow
Thank you Thilo, On Thu, Oct 23, 2025 at 12:25 AM Thilo Molitor <thilo@eightysoft.de> wrote:
In SCRAM (RFC 5802) the client-first-message contains 3 possible values in the GSS-header part: 1. y - The client would have used channel-binding, but the server did not offer any. 2. n - The client does not support channel-binding (even if the server offered any). 3. p=<cb-name> - The name of the channel-binding, the client wants to use.
The RFC explains, that sending "y" when the server advertised channel-binding support is to be used as a MITM-detection: An attacker stripping out all *-PLUS variants can be detected this way (the server knows it advertised them and the client says via "y", that it would have used them if it saw them, so the server can abort the authentication in this case).
This works reasonably well, if there is only one single channel-binding possible. But that's the exact assumption this XEP is going to change: it is possible to advertise a list of different channel-bindings for the client to choose. That's good for protocol agility, something that's important enough to have algorithm negotiation in TLS, for example. I think we all can agree here, that protocol agility is important and so this XEP is needed.
So now we have a problem: what to do if the server advertised a list of channel-binding algorithms, but the client doesn't support any of these? In the non-attacker case, the client can't send "y" in the GSS-header, because the server would then abort the authentication because it advertised channel- bindings. But sending "n" and continuing without channel-binding is fine in this case. This isn't fully hypothetical. An older client might only support tls-unique, while the server only advertises tls-exporter (which can be used for tls 1.2, too, if the extended master secret is used). Blocking the connection entirely is of course at the discretion of the client developer, but it hinders interoperability, especially while phasing out one channel-binding-type and introducing a new one.
Now the attacker case: Any MITM-attacker could just manipulate the list of channel-bindings advertised using this XEP to just list some dummy mechanisms (or mechanisms they know the client doesn't support). That would successfully downgrade the client to non-channel-binding, if the client still sent "n" as above. The client won't be able to distinguish the attacker case from the non- attacker one.
How to fix this while not hindering interoperability? Implementing XEP-0474 is one option (and an even better one). But for defence-in-depth and to support cases when this isn't possible (for example when the SCRAM library used doesn't support adding optional attributes), a few years back I proposed to add a countermeasure to this XEP (the part we are discussing in this thread): Having a MUST to implement and advertise tls-server-end-point when advertising channel-binding types using this XEP. Tls-server-end-point 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, it still catches many attacks (it would have detected the jabber.ru one, for example).
Now with this MUST in place, a client seeing a list without tls-sever-end- point advertised, immediately knows, that some attacker tampered with the list of channel-bindings and can abort the authentication. It never needs to send "n" even though it supports channel-binding and can still safely send "y" if it doesn't see any *-PLUS variants and channel-bindings announced. (Short note: making this a SHOULD or MAY contradicts this, it has to be a MUST here.)
To put what you wrote into actionable terms for the client developer: "If a client sees that that the server has 0440 support it MUST set the 'y' flag regardless of the concrete binding mechanisms announced by the server" Is this a correct summary of what you wrote? If this is basically the justification for making endpoint a requirement then this strategy should by outlined in the Security Considerations because it is definitely not obvious and Conversations for example currently doesn’t do that. This strategy is also somewhat at odds with the statement "Clients using the information provided via <sasl-channel-binding/> MAY want to indicate to the server that they do not support channel-binding (even if they do) if no mutual supported channel-binding type was found." which would have to be replaced then. (Which is fine) Wouldn’t an attacker just strip out the entire 0440 announcement though? Leaving the client developer to have to set the 'n' flag? cheers Daniel
Hi Daniel.
To put what you wrote into actionable terms for the client developer: "If a client sees that that the server has 0440 support it MUST set the 'y' flag regardless of the concrete binding mechanisms announced by the server"
Is this a correct summary of what you wrote? No, no. Lets try to explain it from the client developer perspective. As a client developer, do the following:
0) Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no other (stronger) channel-binding method is supported by both sides. 1) If you don't support channel-binding, you MUST send "n" in the GSS-header (RFC 5802). 2) If you support channel-binding, but you neither got SCRAM-*-PLUS nor XEP-0440 channel-bindings announced by the server, you MUST send "y" (RFC 5802). 3) If you're using SASL2 to authenticate and got SCRAM-*-PLUS, but no XEP-0440 announced, you MUST abort the authentication (this is either an implementation error or MITM). This is undefined with SASL1, but you MAY abort authentication in this case (or just randomly pick a channel-binding and hope for the best). 4) If you're using SASL2 and see XEP-0440 channel-bindings announced, but no SCRAM-*-PLUS methods, you MUST abort authentication (implementation error or MITM). You SHOULD do the same when using SASL1. 5) If you're using SASL1 or SASL2 and see SCRAM-*-PLUS methods and XEP-0440 channel-bindings announced, but *none* of these channel-binding types are supported by you and tls-server-end-point isn't advertised by the server, you MUST abort authentication (this is a MITM, as per rule 0). You SHOULD of course use a channel-binding stronger than tls-server-end-point, if advertised by the server and implemented by you (set the p=<channel-binding-name> GSS- header). 6) All of this applies equally to other mechanisms that, like SCRAM, support channel binding. I hope this makes it more clear. I'm happy to draft a PR to add this list to the XEP, if you want me to. Rule 0 is essentially what we were discussing in this thread. We should move that out of the "Security Considerations" section and replace the entire "Interaction with SASL mechanisms" section with the above list (see below). My explanation why this is needed (from my last mail) could then go into the Security Considerations section.
This strategy is also somewhat at odds with the statement "Clients using the information provided via <sasl-channel-binding/> MAY want to indicate to the server that they do not support channel-binding (even if they do) if no mutual supported channel-binding type was found." which would have to be replaced then. (Which is fine) Yes, essentially the MAY in this section widely opens the door for MITM attacks. Given that I apparently overlooked that section, I withdraw my Last- Call feedback. This XEP should not be advanced before addressing this security issue.
Wouldn’t an attacker just strip out the entire 0440 announcement though? Leaving the client developer to have to set the 'n' flag? No, not when following the above list of rules.
Sidenote regarding SSDP (XEP-0474): When using SSDP to authenticate the channel-binding and mechanism lists, rule 5 SHOULD be relaxed to sending "n" in the GSS-header (even if tls-server-end- point is not announced) and then checking the SSDP signature. If the server doesn't send an SSDP signature, you MUST follow rule 5. If the SSDP signature is wrong, you MUST abort authentication. (If an attacker manipulated the SSDP signature to look right, the server will already abort the authentication later on as per RFC 5802.) -tmolitor Am Donnerstag, 23. Oktober 2025, 08:10:55 CEST schrieb Daniel Gultsch:
Thank you Thilo,
On Thu, Oct 23, 2025 at 12:25 AM Thilo Molitor <thilo@eightysoft.de> wrote:
In SCRAM (RFC 5802) the client-first-message contains 3 possible values in the GSS-header part: 1. y - The client would have used channel-binding, but the server did not offer any. 2. n - The client does not support channel-binding (even if the server offered any). 3. p=<cb-name> - The name of the channel-binding, the client wants to use.
The RFC explains, that sending "y" when the server advertised channel-binding support is to be used as a MITM-detection: An attacker stripping out all *-PLUS variants can be detected this way (the server knows it advertised them and the client says via "y", that it would have used them if it saw them, so the server can abort the authentication in this case).
This works reasonably well, if there is only one single channel-binding possible. But that's the exact assumption this XEP is going to change: it is possible to advertise a list of different channel-bindings for the client to choose. That's good for protocol agility, something that's important enough to have algorithm negotiation in TLS, for example. I think we all can agree here, that protocol agility is important and so this XEP is needed.>
So now we have a problem: what to do if the server advertised a list of channel-binding algorithms, but the client doesn't support any of these? In the non-attacker case, the client can't send "y" in the GSS-header, because the server would then abort the authentication because it advertised channel- bindings. But sending "n" and continuing without channel-binding is fine in this case. This isn't fully hypothetical. An older client might only support tls-unique, while the server only advertises tls-exporter (which can be used for tls 1.2, too, if the extended master secret is used). Blocking the connection entirely is of course at the discretion of the client developer, but it hinders interoperability, especially while phasing out one channel-binding-type and introducing a new one.
Now the attacker case: Any MITM-attacker could just manipulate the list of channel-bindings advertised using this XEP to just list some dummy mechanisms (or mechanisms they know the client doesn't support). That would successfully downgrade the client to non-channel-binding, if the client still sent "n" as above. The client won't be able to distinguish the attacker case from the non- attacker one.
How to fix this while not hindering interoperability? Implementing XEP-0474 is one option (and an even better one). But for defence-in-depth and to support cases when this isn't possible (for example when the SCRAM library used doesn't support adding optional attributes), a few years back I proposed to add a countermeasure to this XEP (the part we are discussing in this thread): Having a MUST to implement and advertise tls-server-end-point when advertising channel-binding types using this XEP. Tls-server-end-point 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, it still catches many attacks (it would have detected the jabber.ru one, for example).
Now with this MUST in place, a client seeing a list without tls-sever-end- point advertised, immediately knows, that some attacker tampered with the list of channel-bindings and can abort the authentication. It never needs to send "n" even though it supports channel-binding and can still safely send "y" if it doesn't see any *-PLUS variants and channel-bindings announced. (Short note: making this a SHOULD or MAY contradicts this, it has to be a MUST here.)
To put what you wrote into actionable terms for the client developer: "If a client sees that that the server has 0440 support it MUST set the 'y' flag regardless of the concrete binding mechanisms announced by the server"
Is this a correct summary of what you wrote?
If this is basically the justification for making endpoint a requirement then this strategy should by outlined in the Security Considerations because it is definitely not obvious and Conversations for example currently doesn’t do that. This strategy is also somewhat at odds with the statement "Clients using the information provided via <sasl-channel-binding/> MAY want to indicate to the server that they do not support channel-binding (even if they do) if no mutual supported channel-binding type was found." which would have to be replaced then. (Which is fine)
Wouldn’t an attacker just strip out the entire 0440 announcement though? Leaving the client developer to have to set the 'n' flag?
cheers Daniel _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Thilo Molitor <thilo@eightysoft.de> writes:
Hi Daniel.
To put what you wrote into actionable terms for the client developer: "If a client sees that that the server has 0440 support it MUST set the 'y' flag regardless of the concrete binding mechanisms announced by the server"
Is this a correct summary of what you wrote? No, no. Lets try to explain it from the client developer perspective. As a client developer, do the following:
0) Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no other (stronger) channel-binding method is supported by both sides.
I think that would be horrible advice these days -- the tls-server-end-point gives a false sense of security and is known sub-optimal for years. It would be similar to urge people to MUST implement 3DES or RC4 for TLS. There is no fatal attack for those either, but the collective wisdom is "don't use them". I suggest to mandate tls-exporter from RFC 9266. I believe any deployment not being able to support this is better off not supporting channel bindings at all, because doing so just adds complexity and attack surface and end-user confusion ("oh nice I have a channel binding!") for little gain. /Simon
0) Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no other (stronger) channel-binding method is supported by both sides.
I think that would be horrible advice these days -- the tls-server-end-point gives a false sense of security and is known sub-optimal for years. It would be similar to urge people to MUST implement 3DES or RC4 for TLS. There is no fatal attack for those either, but the collective wisdom is "don't use them".
I suggest to mandate tls-exporter from RFC 9266. I believe any deployment not being able to support this is better off not supporting channel bindings at all, because doing so just adds complexity and attack surface and end-user confusion ("oh nice I have a channel binding!") for little gain.
I really object! tls-server-end-point is vastly better than no channel-binding at all! If you need a real world example: It would have prevented the jabber.ru attack. I get that its not the best channel-binding we have at hand here, but that MUST in rule 0 isn't a "please don't do better", but rather a "please don't do worse". Its a *minimal* requirement. And like others already said, there are deployments that can't do exporter. Preventing them from being able to do channel-binding at all would be very bad. And yes, using tls-exporter as "minimal" requirement instead would do exactly that: prevent channel-binding at all. See, you need a channel-binding that can be implemented and deployed in *absolutely* all scenarios, for my list of rules to work and block the attack in rule 5. Tls-exporter just doesn't meet that requirement. Even worse: just doing an s/tls-server-endpoint/tls-exporter in these rules will not only render rule 5 completely useless, but make it harmful: it would block all deployments only being able to do tls-server-end-point. Those deployments would need to turn off channel-binding completely to allow clients following those rules to authenticate at all. So I ask you: do you want to block all deployments using tls-server-end-point from using channel-binding at all, substantially lowering their security, just because having tls-exporter named in a XEP feels better than tls-server-end- point? We can always name tls-exporter explicitly in the XEP, though. Maybe something like: Servers and clients SHOULD implement a stronger channel- binding like tls-exporter, if at all possible. -tmolitor
Thank you Thilo. On Fri, Oct 24, 2025 at 4:00 AM Thilo Molitor <thilo@eightysoft.de> wrote:
To put what you wrote into actionable terms for the client developer: "If a client sees that that the server has 0440 support it MUST set the 'y' flag regardless of the concrete binding mechanisms announced by the server"
Is this a correct summary of what you wrote? No, no. Lets try to explain it from the client developer perspective. As a client developer, do the following:
0) Servers MUST implement tls-server-end-point and enable/advertise it. Clients SHOULD implement tls-server-end-point and use it if no other (stronger) channel-binding method is supported by both sides.
1) If you don't support channel-binding, you MUST send "n" in the GSS-header (RFC 5802).
2) If you support channel-binding, but you neither got SCRAM-*-PLUS nor XEP-0440 channel-bindings announced by the server, you MUST send "y" (RFC 5802).
3) If you're using SASL2 to authenticate and got SCRAM-*-PLUS, but no XEP-0440 announced, you MUST abort the authentication (this is either an implementation error or MITM). This is undefined with SASL1, but you MAY abort authentication in this case (or just randomly pick a channel-binding and hope for the best).
4) If you're using SASL2 and see XEP-0440 channel-bindings announced, but no SCRAM-*-PLUS methods, you MUST abort authentication (implementation error or MITM). You SHOULD do the same when using SASL1.
5) If you're using SASL1 or SASL2 and see SCRAM-*-PLUS methods and XEP-0440 channel-bindings announced, but *none* of these channel-binding types are supported by you and tls-server-end-point isn't advertised by the server, you MUST abort authentication (this is a MITM, as per rule 0). You SHOULD of course use a channel-binding stronger than tls-server-end-point, if advertised by the server and implemented by you (set the p=<channel-binding-name> GSS- header).
6) All of this applies equally to other mechanisms that, like SCRAM, support channel binding.
Yes I guess with this ruleset in place defining a common, mandatory to implement channel binding mechanism makes sense. But this set of rules is definitely not obvious and I wasn’t really aware of that even though I consider myself as having some experience with the whole channel binding/SASL2 stack. So yeah. IDK. scrap the entire Security Considerations and replace it with that. ^
I hope this makes it more clear. I'm happy to draft a PR to add this list to the XEP, if you want me to.
Rule 0 is essentially what we were discussing in this thread.
Yeah. But until now we have been discussing it without the context.
We should move that out of the "Security Considerations" section and replace the entire "Interaction with SASL mechanisms" section with the above list (see below). My explanation why this is needed (from my last mail) could then go into the Security Considerations section.
Yeah I don’t have strong feelings of where in the XEP to put exactly what. But this should probably all go somewhere. In any case all that are only arguments for having one required binding mechanism. This still leaves the question if enough time has passed that we can make exporter that mechanism. cheers Daniel
On Fri, Oct 24, 2025 at 12:24 PM Daniel Gultsch <daniel@gultsch.de> wrote:
In any case all that are only arguments for having one required binding mechanism. This still leaves the question if enough time has passed that we can make exporter that mechanism.
To be clear. Personally I don’t have strong feelings on endpoint v exporter. I think endpoint is sort of fine for a lot of cases but I also don’t think it’s a big deal to pull in a bouncy castle dependency into your java software. However with my council hat on I’m not seeing a rough consensus on the endpoint v exporter. Both sides seem to have ~3 fairly loud supporters. I guess we can start of by reworking the security considerations and interaction with SCRAM (y,n flags) so we have the justifications for "a" common mechanism in the XEP. And then s/endpoint/exporter/ is a fairly minor step we can decide to do or not to do.
Hi Daniel. Am Freitag, 24. Oktober 2025, 12:44:05 CEST schrieb Daniel Gultsch:
On Fri, Oct 24, 2025 at 12:24 PM Daniel Gultsch <daniel@gultsch.de> wrote:
In any case all that are only arguments for having one required binding mechanism. This still leaves the question if enough time has passed that we can make exporter that mechanism.
To be clear. Personally I don’t have strong feelings on endpoint v exporter. I think endpoint is sort of fine for a lot of cases but I also don’t think it’s a big deal to pull in a bouncy castle dependency into your java software.
Well, while I'd love to see tls-exporter used here, I don't see that happen any time soon. We need a channel-binding *absolutely* every server (and client) could implement and use. Otherwise servers not offering this would mistakenly be seen as MITMed. Servers behind a TLS terminator / load balancer etc. would all suddenly stop working with those clients following the rules of my last mail. And at that point, client developers might give in to the complaints of users/ server operators and stop following these rules at all, creating a MITM security vulnerability in these clients.
I guess we can start of by reworking the security considerations and interaction with SCRAM (y,n flags) so we have the justifications for "a" common mechanism in the XEP. And then s/endpoint/exporter/ is a fairly minor step we can decide to do or not to do. I'll craft a PR :)
-tmolitor
On Wed, 8 May 2024 at 02:35, Travis Burtrum <travis@burtrum.org> wrote:
Hi all,
On 5/6/24 1:21 PM, Daniel Gultsch wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No. And in fact it opens gaps.
2. Does the specification solve the problem stated in the introduction and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with the MITM themselves.
The particular attack is discussed (with some typos, and I think a slight lack of clarity) in the Security Considerations, but actually it already exists, so there is no effective change to security via the specification; just a change to ease of use and adoption of better security.
3. Do you plan to implement this specification in your code? If not, why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes. This specification? No.
4. Do you have any security concerns related to this specification?
So many.
1. it gives a MUST for servers and SHOULD for clients to implement tls-server-end-point which is weak and likely shouldn't be implemented at all. Note TLS-intercepting-proxies can implement the strong tls-exporter just fine by simply passing the keying material to the backend server. See
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA3... for more discussion.
Yes, but they do not, and no amount of saying that AWS could implement this will cause them to do so. So for practicality, the question becomes "assuming that tls-exporter is not possible, as is the case in many current deployments, does recommending tls-server-endpoint improve security", and I think it's fairly clear it does. Ideal? No. Improved? Yes. At least a bit.
2. tls-unique is broken by https://www.mitls.org/pages/attacks/3SHAKE and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your client-side TLS library and config meets a ton of ifs. It has to implement the extended master secret extension *and* the server has to negotiate this. (remember, the server here is the potential attacker, so it would just... not).
So to securely implement tls-unique a client would need to *require* negotiation of the extended master secret extension for TLS 1.2 connections and fail to connect otherwise. How many clients do this? How many clients have any idea whether their TLS lib supports or enforces this? How many TLS libs even let you check this?
We must assume tls-unique is not to be trusted.
This is all very good, but the specification does not mention tls-unique.
3. That leaves tls-exporter as the only secure channel binding method.
One method doesn't need negotiation. A wise person recently said "parameterize of security protocols and algorithms are generally a bad idea as it adds complexity which reduces security."
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4H...
This spec in particular says to nicely ask the attacker if they support it before doing it... and the attacker will just say no. The XEP handwaves this security destroying attack as a "well clients could pin channel bindings" not even a MAY, SHOULD, or MUST. Do any implementations today do this? If not it is just feel good security theater that gives absolutely no security against a MITM.
Your argument is that everyone should do everything. For what it's worth, I broadly agree that this is a desirable end-goal. However, getting There from Here is the problem this specification is attempting to address. The specification says - quite clearly, though I agree it could be improved - that a client might try using tls-exporter whether it's advertised or not. So if you want to do what you're describing, the specification doesn't preclude that, and that's a good thing. But for the vast majority of cases, clients might be avoiding tls-exporter because it might give an error during authentication. SCRAM can actually tell you that the authentication failed because the channel-binding type is not supported - but an active attacker can spoof that just as well as this specification, with exactly the same ease, so I think it's important to note that the security is the same with or without this specification - but it might help adoption. Dave.
Hi Travis, Thanks for your mail. I am sorry that xep440 failed to communicate its goal, as it seems. I will try to improve upon that. You write that tls-server-end-point should not be used and that TLS-intercepting proxies can implement tls-exporter "just fine by simply passing the keying material". You are correct that tls-server-end-point has issues. However, using tls-exporter with TLS-intercepting proxies is not immediately available. As you write in the linked mailing list thread, it requires extensions to the protocol. You write that 3SHAKE and SLOTH break tls-unique and that tls-unique should be only used if the extended master secret extension has been negotiated. This is also correct and the reason why most specifications require tls-unique to be only used when the extended master secret extension has been negotiated. Ultimately, you should use tls-exporter with TLS 1.3 and nothing else. I think it is fair to say that we both agree on this. However, the idealized world often does not match the real world. Displaying a "this is an untrusted certificate" on every connection that does *not* use tls-exporter and TLS 1.3 is probably not sensible at the moment. I hope that it will be in the future, though. I've been told that around 90% of all connections to jabber.fr are already using TLS 1.3. However, the availability of APIs that allow to obtain the tls-exporter data from your TLS implementation is probably the major obstacle for adoption. Therefore, if you want to provide channel binding, you have to consider other channel-binding mechanisms. Even weaker channel binding mechanisms than tls-exporter raise the bar for MiTM attacks. Under this assumption, I believe the best thing we can currently provide is xep440. Yes, you interact with a potential MiTM when doing xep440 feature negotiation. The only way around that would be to move the functionality provided by xep440 down to the TLS level. Unfortunately, there is no specification for this. And under those constraints, pinning is the only left defensive measure. Pinning narrows the time window of a MiTM attack significantly, reducing the number of potential victims. Note that xep440 does not prevent clients from implementing more secure strategies, like always attempting tls-exporter first and then pinning tls-exporter once it is successful. In summary, even though it is not ideal, there is value in xep440. - Flow
Can we see if the Kitten IETF list (which tends to cover the use of TLS channel bindings with SASL mechanisms) has any comments on this before advancing it? I appreciate this is a departure from our process, strictly speaking, but it feels like a bit of outreach might benefit this and we could consider it part of the Last Call. Dave. On Mon, 6 May 2024 at 18:22, 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 2024-05-20.
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
I'm a bit torn on this one. Mostly I agree with what Travis wrote. I'm slightly concerned that the way this spec makes recommendations (ie. putting exporter and end-point at the same level of "SHOULD" [1]) may lead to a false sense of security (this is already true of most everywhere we write about tls-end-point where we don't make it clear that it provides vastly different security properties than unique mechanisms like tls-unique and tls-exporter). I also strongly agree with Dave that we should run this by KITTEN first; asking the advice of the experts seems pertinent. Overall I'm not against having a way to do this negotiation: if tls-exporter starts showing signs of weaknesses it's probably good to have a way to quickly update. But I'm somewhat against this document making recommendations for compatibility and would prefer that to exist elsewhere (probably somewhere we can update quicker than a standards track XEP if future problems arise; maybe we should have a "how to use TLS with XMPP" informational spec of our own at some point? Finally, I'd like to see a trust-on-first-use model added to the spec. If we're going to do this, the client may want to cache the mechanism list on the first connection to the server and fail if that list is downgraded in the future, or something along those lines. TL;DR — overall I'm not against the general idea, but I don't think this spec is ready for last call yet. —Sam [1]: actually, it looks like tls-exporter isn't even a SHOULD, it's a "should". That SHOULD probably be fixed :) On 2024-05-06 13:21, Daniel Gultsch 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 2024-05-20.
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
-- Sam Whited sam@samwhited.com
On 5/8/24 8:12 AM, Sam Whited wrote:
maybe we should have a "how to use TLS with XMPP" informational spec of our own at some point?
Thijs Alkemade and I wrote RFC 7590 [1] for that purpose, but it was published in 2015 (via the UTA WG) and much has changed since then. Peter [1] https://www.rfc-editor.org/rfc/rfc7590.html
participants (9)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Marvin W -
Peter Saint-Andre -
Sam Whited -
Simon Josefsson -
Thilo Molitor -
Travis Burtrum