XEP-0440 and tls-server-end-point
Hi I was reading XEP-0440 and noticed that since 2022-08 it requires support for tls-server-end-point channel bindings. I believe this is unfortunate because tls-server-end-point channel binding are worse than either of tls-unique or tls-exporter. Mandating support for this weak channel binding will detract from efforts to implement the stronger tls-unique and tls-exporter. When deciding what to prioritize, it may be that someone believes that since XEP-0440 requires tls-server-end-point, it is more important to implement it than spend time getting tls-exporter implemented. That would be a bad outcome. I suggest changing XEP-0440 to require tls-unique when TLS <= 1.2 is used and tls-exporter when TLS >= 1.3 is used. If you have already given up on supporting TLS <= 1.2 I think you should only mandate tls-exporter as this is the best available channel binding available. I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter. /Simon
* Simon Josefsson <simon@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. Holger
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.
Wiadomość napisana przez Holger Weiß <holger@zedat.fu-berlin.de> w dniu 11.01.2024, o godz. 13:39:
* Simon Josefsson <simon@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.
Holger _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Regards, Andrzej Wójcik XMPP: andrzej.wojcik@tigase.org Email: andrzej.wojcik@tigase.net
Hi Simon, thanks for your mail. On 11/01/2024 13.39, Holger Weiß wrote:
* Simon Josefsson <simon@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. - Flow
tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
* Simon Josefsson <simon@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.
Indeed -- however I think the burden to support those kind of environments should be on the entities chosing to deploy and use those kind of environments, instead of placing the burden (and weakening security) for everyone else. While I think it is acceptable for standards to acknowledge and allow insecure usage modes (with proper caveats), I believe the primary purpose and default recommendations for a standard should be to promote secure behaviour. That is not achieved in XEP-0440 now. A compromise would be to mandate both tls-exporter and tls-server-end- point, however I'm hoping the short period that tls-server-end-point has been mandated can be ignored and we can select a better mandatory method. /Simon
On Thu, 11 Jan 2024 at 12:49, Simon Josefsson <simon@josefsson.org> wrote:
tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
* Simon Josefsson <simon@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.
Indeed -- however I think the burden to support those kind of environments should be on the entities chosing to deploy and use those kind of environments, instead of placing the burden (and weakening security) for everyone else.
While I think it is acceptable for standards to acknowledge and allow insecure usage modes (with proper caveats), I believe the primary purpose and default recommendations for a standard should be to promote secure behaviour. That is not achieved in XEP-0440 now.
A compromise would be to mandate both tls-exporter and tls-server-end- point, however I'm hoping the short period that tls-server-end-point has been mandated can be ignored and we can select a better mandatory method.
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
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 <simon@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. 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
Dear all, coincidentally I was implementing `tls-server-end-point` channel binding for go-sendxmpp this morning. As a client can choose the method to use I don't see an issue here. I just prefer `tls-exporter` if TLSv1.3 is used and `tls-unique` otherwise and only use `tls-server-end-point` when it's the only method offered. As Holger and Andrzej pointed out there might be cases where the better methods are not available and using a weaker one is still better than no channel binding at all. Best regards, Martin
On Thu, 11 Jan 2024 at 12:39, Holger Weiß <holger@zedat.fu-berlin.de> wrote:
* Simon Josefsson <simon@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.
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.
On 1/11/24 10:37, Dave Cridland wrote:
On Thu, 11 Jan 2024 at 12:39, Holger Weiß <holger@zedat.fu-berlin.de <mailto:holger@zedat.fu-berlin.de>> wrote:
* Simon Josefsson <simon@josefsson.org <mailto:simon@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.
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.
Also the TLS terminating proxy can pass the required secrets for "real channel binding" to the backend XMPP server via extensions to the PROXY protocol. I plan on adding support for this to xmpp-proxy soon.
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 <simon@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? - Flow 1: https://github.com/igniterealtime/Smack/blob/e504bc23cfe601e4e414aac1aff54c8...
On Tue, 30 Jan 2024 at 10:11, Florian Schmaus <flo@geekplace.eu> wrote:
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?
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.
participants (8)
-
Andrzej Wójcik -
Dave Cridland -
Florian Schmaus -
Holger Weiß -
Martin Dosch -
Matthew Wild -
Simon Josefsson -
Travis Burtrum