[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

Hi all, On 5/6/24 1:21 PM, Daniel Gultsch wrote: No. And in fact it opens gaps. It enables negotiating a feature meant to prevent/detect MITMs with the MITM themselves. MITM attack mitigation via public key pinning and tls-exporter? Yes. This specification? No. 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/MBNEF3NMA… 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/DFWL7RSQ4… 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. 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