TLS Channel-Binding Downgrade Protection This specification provides a way to secure the SASL and SASL2 SCRAM handshakes against channel-binding downgrades through TLS version downgrades. This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA). xxxx ProtoXEP Standards Track Standards Council XMPP Core RFC 5802 XEP-0388 TDP downgade protection tls scram channel-binding Thilo Molitor thilo+xmpp@eightysoft.de thilo.molitor@juforum.de 0.0.1 2026-03-14 tm Initial version.

SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>. defines a way to detect and prevent channel-binding type and SASL method downgrades. While this works well, an attacker could still leverage one specific attack vector to downgrade the channel-binding type to tls-server-end-point: a MITM-attacker could use different TLS versions with a different set of supported channel-binding types on both arms of their connection. This will downgrade the channel-binding type negotiated to the lowest denominator of both lists, which is at least tls-server-end-point per requirement of SASL Channel-Binding Type Capability (XEP-0440) XEP-0440: SASL Channel-Binding Type Capability <https://xmpp.org/extensions/xep-0440.html>.. If the server violates point 1 of the Business Rules in SASL Channel-Binding Type Capability (XEP-0440) XEP-0440: SASL Channel-Binding Type Capability <https://xmpp.org/extensions/xep-0440.html>. and the client simultaneously violates point 6 in said Business Rules, the attacker will even be able to downgrade the connection no channel-binding at all!

While pinning of channel-binding types can prevent those downgrade attacks, pinning comes with all the downsides explained in SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>. and won't secure the very first connection either.

While this attack doesn't depend on specific TLS versions, but can be executed with all current or future TLS versions for which the list of defined/implemented channel-binding types differes, here are two examples for TLS 1.2 and TLS 1.3.

If the MITM-attacker terminates the TLS connection to the client with TLS 1.3 and the TLS connection to the server with TLs 1.2, the server will advertise tls-uniqe channel-binding (alongside tls-server-end-point), but not tls-exporter. The client won't pick tls-unique, because it isn't defined for TLS 1.3 and fall back to the weaker tls-server-end-point.

If the MITM-attacker chooses to terminate the TLS connection to the client with TLS 1.2 and to the server with TLS 1.3, the server will advertise tls-exporter channel-binding (alongside tls-server-end-point), but not tls-unique. Even though tls-exporter can be securely used if the extended-master-secret extension TLS extension is used, most clients won't pick tls-exporter on TLS 1.2 connections and thus fall back to the weaker tls-server-end-point.

This specification uses some abbreviations:

This protocol was designed with the following requirements in mind:

Note that this specification intentionally leaves out support for SASL PLAIN. If server and client support PLAIN, no protection against SASL method or channel-binding downgrades is possible and the security relies solely on the underlying TLS channel. See the Business Rules section of SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>. for some advice on how to handle PLAIN.

Sections 5.1 and 7 of RFC 5802 RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>. allow for arbitrary optional attributes inside SCRAM messages. This specification uses those optional attributes to implement a downgrade protection.

The server encodes the TLS version number used by the connection as defined in RFC 8446 RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 <http://tools.ietf.org/html/rfc8446>., RFC 5246 RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <http://tools.ietf.org/html/rfc5246>. and their predecessors as four lowercased hexadecimal numbers. For convenience the currently defined version numbers follow:

  1. TLS 1.3 has the version number 0x0304, thus is encoded as '0304'
  2. TLS 1.2 has the version number 0x0303, thus is encoded as '0303'
  3. TLS 1.1 has the version number 0x0302, thus is encoded as '0302'
  4. TLS 1.0 has the version number 0x0301, thus is encoded as '0301'

The server then adds the optional attribute "t" with the value of the four hexadecimal characters described above to its server-first-message.

Upon receiving the server-first-message the client calculates the version number of its own TLS connection and encodes it as four lowercased hex-encoded characters as described in Server Sends TLS Version As Hex.

The client then extracts the TLS version number presented by the server in the optional attribute "t" and compares it to its own version number. If the hex-encoded version numbers match, the TLS version used by the server and client have not been altered by an active MITM.

If the version numbers do not match, the client MUST fail the authentication. It MAY additionally show a user-facing warning message about an active MITM. If the version numbers match, an attacker could still have manipulated them. If so, the server will always fail the authentication according to RFC 5802 RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>. because the client-proof will not be based upon the correct TDP value.

This sections contains an example based on the ones provided in Extensible SASL Profile (XEP-0388) XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>..

SCRAM-SHA-1 SCRAM-SHA-1-PLUS cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNg== AwesomeXMPP Kiva's Phone cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5NixoPUc2ay9yQkxEcWdPaFJSYUN1dWF0U0RGa0owOD0sdD0wMzA0 Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xGUklTVk1nU1ZNZ1JrRkxSU0JEUWlCRVFWUkIscj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscD1LSFVmTjhkU3kxSzk1Y3JUNEQ1eTFJdExKZnM9 dj0zdzM0WklNVlJreDJmMk96YjMvZWNSUFZkdjQ9 user@example.org ]]>

To implement this protocol, clients and servers MUST also implement SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>..

The rules outlined in the Business Rules section of SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>. are important and MUST be followed when implementing this specification.

Using SCRAM attributes makes them part of the HMAC signatures used in the SCRAM protocol flow, efficiently protecting them against any MITM attacker not knowing the password used.

This protocol shall be superseded by any IETF RFC providing some or all of the functionality provided by this specification. If such a specification exists implementations SHOULD NOT implement this XEP and SHOULD implement the superseding RFC instead.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..

Thanks to Holger Weiß and Paweł Chmielowski for their feedback.

This specification does not need any interaction with the XMPP Registrar The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>..

This specification does not specify any new XML elements.