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/standards@xmpp.org/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/standards@xmpp.org/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.