[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

I'm a bit torn on this one. Mostly I agree with what Travis wrote. I'm slightly concerned that the way this spec makes recommendations (ie. putting exporter and end-point at the same level of "SHOULD" [1]) may lead to a false sense of security (this is already true of most everywhere we write about tls-end-point where we don't make it clear that it provides vastly different security properties than unique mechanisms like tls-unique and tls-exporter). I also strongly agree with Dave that we should run this by KITTEN first; asking the advice of the experts seems pertinent. Overall I'm not against having a way to do this negotiation: if tls-exporter starts showing signs of weaknesses it's probably good to have a way to quickly update. But I'm somewhat against this document making recommendations for compatibility and would prefer that to exist elsewhere (probably somewhere we can update quicker than a standards track XEP if future problems arise; maybe we should have a "how to use TLS with XMPP" informational spec of our own at some point? Finally, I'd like to see a trust-on-first-use model added to the spec. If we're going to do this, the client may want to cache the mechanism list on the first connection to the server and fail if that list is downgraded in the future, or something along those lines. TL;DR — overall I'm not against the general idea, but I don't think this spec is ready for last call yet. —Sam [1]: actually, it looks like tls-exporter isn't even a SHOULD, it's a "should". That SHOULD probably be fixed :) On 2024-05-06 13:21, Daniel Gultsch wrote: -- Sam Whited sam(a)samwhited.com