On 11/01/2024 14.03, Simon Josefsson wrote:
tor 2024-01-11 klockan 13:48 +0100 skrev Florian Schmaus:Hi Simon,thanks for your mail. On 11/01/2024 13.39, Holger Weiß wrote:* Simon Josefsson <si...@josefsson.org> [2024-01-11 13:10]:I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter.One use case I see for tls-server-end-point is that it allows for supporting channel binding by setups where TLS is terminated by some reverse proxy, thereby protecting against _some_ but not all attack vectors that tls-exporter protects against.Additionally, implementing tls-server-end-point demands minimal effort since it is just based on the hash of the certificate. I believe that not making it mandatory won't deter anyone who is inclined to implement it, as it is a low hanging fruit. Furthermore, we hope to achieve a high success rate by making it mandatory to implement for servers. You are correct, one should aim for better altnatives than tls-server-end-point when implementing XEP-0440, and this should be explicitly mentioned in the XEP. As it stands, the XEP does not clearly convey this. I intend to propose a revision to rectify this in the near future.Thanks Florian. Extracting the correct certificate from the TLS library, hashing it using the right algorithm, and getting that into a SCRAM library that support tls-server-end-point may be as easy or challenging as support for tls-exporter. So I'm not as convinced tls- server-end-point is minimal effort.
It's a few lines of code in Java to extract the channel-binding data for tls-server-end-point from a SSLSession using only API from Java's runtime library [1].
The situation is vastly different for tls-exporter. Last time I've checked, there was no API in the Java's runtime library to retrieve the tls-exporter. So you have to resort to third party libraries, which increases your code complexity (it's usually nicer if you can just rely on the API of the standard library of your programming language's ecosystem.
In my experience you find APIs to retrieve the tls-server-end-point data pretty easily. Getting the tls-exporter data can be tricky. It can even be impossible, I believe, though the situation may has improved over the last years.
What do you think about a compromise to mandate support for both tls- server-end-point and tls-exporter? I'd prefer only tls-exporter though.
Mandating tls-exporter gets you nothing if people can not implement it. I think this is fallacy many standards organizations fall for. We also have to look at the software ecosystem and its capabilities.
Are you positive that it is sufficiently easy to retrieve tls-exporter data from a TLS session in all ecosystems of "relevant" programming languages?
If we are not positive about it, then why should be push implementations into non-compliance by mandating it, when we simply could (strongly) recommend it?
- Flow1: https://github.com/igniterealtime/Smack/blob/e504bc23cfe601e4e414aac1aff54c8f3d69c67f/smack-core/src/main/java/org/jivesoftware/smack/util/TLSUtils.java#L197
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
