Hi Daniel. Am Freitag, 24. Oktober 2025, 12:44:05 CEST schrieb Daniel Gultsch: > On Fri, Oct 24, 2025 at 12:24 PM Daniel Gultsch <[email protected]> wrote: > > > > In any case all that are only arguments for having one required > > binding mechanism. This still leaves the question if enough time has > > passed that we can make exporter that mechanism. > > > To be clear. Personally I don’t have strong feelings on endpoint v > exporter. I think endpoint is sort of fine for a lot of cases but I > also don’t think it’s a big deal to pull in a bouncy castle dependency > into your java software.
Well, while I'd love to see tls-exporter used here, I don't see that happen any time soon. We need a channel-binding *absolutely* every server (and client) could implement and use. Otherwise servers not offering this would mistakenly be seen as MITMed. Servers behind a TLS terminator / load balancer etc. would all suddenly stop working with those clients following the rules of my last mail. And at that point, client developers might give in to the complaints of users/ server operators and stop following these rules at all, creating a MITM security vulnerability in these clients. > I guess we can start of by reworking the security considerations and > interaction with SCRAM (y,n flags) so we have the justifications for > "a" common mechanism in the XEP. And then s/endpoint/exporter/ is a > fairly minor step we can decide to do or not to do. I'll craft a PR :) -tmolitor _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
