Hi Travis,

Thanks for your mail.

I am sorry that xep440 failed to communicate its goal, as it seems. I will try to improve upon that.

You write that tls-server-end-point should not be used and that TLS-intercepting proxies can implement tls-exporter "just fine by simply passing the keying material". You are correct that tls-server-end-point has issues. However, using tls-exporter with TLS-intercepting proxies is not immediately available. As you write in the linked mailing list thread, it requires extensions to the protocol.

You write that 3SHAKE and SLOTH break tls-unique and that tls-unique should be only used if the extended master secret extension has been negotiated. This is also correct and the reason why most specifications require tls-unique to be only used when the extended master secret extension has been negotiated.

Ultimately, you should use tls-exporter with TLS 1.3 and nothing else. I think it is fair to say that we both agree on this.

However, the idealized world often does not match the real world.

Displaying a "this is an untrusted certificate" on every connection that does *not* use tls-exporter and TLS 1.3 is probably not sensible at the moment. I hope that it will be in the future, though. I've been told that around 90% of all connections to jabber.fr are already using TLS 1.3. However, the availability of APIs that allow to obtain the tls-exporter data from your TLS implementation is probably the major obstacle for adoption.

Therefore, if you want to provide channel binding, you have to consider other channel-binding mechanisms. Even weaker channel binding mechanisms than tls-exporter raise the bar for MiTM attacks.

Under this assumption, I believe the best thing we can currently provide is xep440.

Yes, you interact with a potential MiTM when doing xep440 feature negotiation. The only way around that would be to move the functionality provided by xep440 down to the TLS level. Unfortunately, there is no specification for this. And under those constraints, pinning is the only left defensive measure. Pinning narrows the time window of a MiTM attack significantly, reducing the number of potential victims.

Note that xep440 does not prevent clients from implementing more secure strategies, like always attempting tls-exporter first and then pinning tls-exporter once it is successful.

In summary, even though it is not ideal, there is value in xep440.

- Flow

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

Reply via email to