On Wed, 8 May 2024 at 02:35, Travis Burtrum <[email protected]> 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/[email protected]/thread/MBNEF3NMA3UDD4SKULEY7AZCA3TV4I5P/?sort=date > 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/[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. > > 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.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
