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/[email protected]/thread/MBNEF3NMA3UDD4SKULEY7AZCA3TV4I5P/?sort=date > > 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/[email protected]/thread/DFWL7RSQ4HY5CR66BS46SJ4GTS6D7BOF/ > > 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
