Another use case of tls-server-end-point is for cases where you are unable to support tls-exporter, ie. in some languages TLS/SSL stack doesn’t expose data required for tls-exporter. In those cases it is better to have tls-server-end-point for channel binding instead of not having anything available. Regards, Andrzej Wójcik XMPP: andrzej.wojcik(a)tigase.org Email: andrzej.wojcik(a)tigase.net

tor 2024-01-11 klockan 13:48 +0100 skrev Florian Schmaus: 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. Remember, tls-server-end-point has pretty detailed requirement of which certificate in the chain to hash, and what hash algorithm to use that is not future proof. The simplicity of this depends on the TLS and SASL/SCRAM library that are used. For modern libraries, I believe that tls-exporter should be easier and more efficient than tls-server-end- point. RFC 5929 on tls-server-end-point: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message. Note that the Certificate message contains a certificate_list, in which the first element is the server's certificate. The hash function is to be selected as follows: o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174], then use SHA-256 [FIPS-180-3]; o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm; o if the certificate's signatureAlgorithm uses no hash functions or uses multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises). 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. /Simon

On Tue, 30 Jan 2024 at 10:11, Florian Schmaus <flo(a)geekplace.eu> wrote: Exactly this - interoperability should be a pragmatically achievable goal. Security should be as high as possible without disrupting that goal, because if it's disrupted then people will just use something else that actually works, and the additional requirements have achieved nothing. Given this, tls-server-end-point seems like it ought to be baseline - it's relatively easy to implement anywhere, and while it has weaknesses, it's still a lot better than nothing. So that says, to me, text along the lines of "MUST implement". tls-exporter is clearly superior, so we want to encourage that, but accept there are lots of cases where that's not practical, so "SHOULD implement". Finally, we know that in some deployments, there is enough control of clients and other deployment aspects that there's no practical benefit to supporting the weaker tls-server-end-point, so we might want to indicate that while deployment in the general case is "strongly advised" (I'm side-stepping RFC 2119 here), if a particular deployment can remove it that's actually better security. Dave.

On Thu, 11 Jan 2024 at 12:49, Simon Josefsson <simon(a)josefsson.org> wrote: Thankfully I think all server implementations took sensible routes already (i.e. everyone who supports channel binding has tls-exporter implemented, in current or current+1 releases). Prosody will automatically offer tls-unique/tls-exporter, and tls-server-end-point by default unless explicitly configured by the admin. I think the logic for the wording in the XEP was because some deployments cannot (easily) use the algorithms with dynamic values, so tls-server-end-point is seen as the lowest common denominator, and recommended from an interoperability perspective (some channel binding is better than none at all). However I think that the difficulties deploying tls-unique/tls-exporter that exist today could be overcome with sufficient support from TLS middleware. I'm not aware of any such support right now though. Regards, Matthew

On Thu, 11 Jan 2024 at 12:39, Holger Weiß <holger(a)zedat.fu-berlin.de> wrote: I'm pretty sure this was a key reason we picked the approach. If TLS is terminated before the server ever sees it, the server can still be configured to handle tls-server-end-point. It's not, of course, really channel binding - it's not binding to the channel itself at all - but it does give some of the protection real channel binding would. Dave.