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]
