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:

On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440: 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. 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

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 Sat, 18 Oct 2025 at 17:32, Daniel Gultsch &lt;daniel(a)gultsch.de&gt; wrote: 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. 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?)

On Mon, 20 Oct 2025 at 14:55, Peter Saint-Andre &lt;stpeter(a)stpeter.im&gt; wrote: 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 Mon, Oct 20, 2025 at 12:47 PM Dave Cridland &lt;dave(a)cridland.net&gt; wrote: 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. FWIW WebTransport is close to ready and has exporter support. 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.

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.

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:

Hi Daniel. 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. 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. 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: GSS-header part: any. any). support is to be used as a MITM-detection: server knows it advertised them and the client says via "y", that to choose. That's good for protocol agility, something that's the server would then abort the authentication because it while the server only advertises tls-exporter (which can be developer, but it hinders interoperability, especially while (or mechanisms they know the client doesn't support). That one option (and an even better one). But for unique, it still catches many attacks (it would have detected the 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.) > > > > 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. > > 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(a)xmpp.org > To unsubscribe send an email to standards-leave(a)xmpp.org

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

On Fri, Oct 24, 2025 at 12:24 PM Daniel Gultsch &lt;daniel(a)gultsch.de&gt; wrote: 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.

On Wed, 8 May 2024 at 02:35, Travis Burtrum &lt;travis(a)burtrum.org&gt; wrote: 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. 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. This is all very good, but the specification does not mention tls-unique. 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.

On 5/8/24 8:12 AM, Sam Whited wrote: 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