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:
This message constitutes notice of a Last Call for comments on XEP-0440.
Title: SASL Channel-Binding Type Capability Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on 2024-05-20.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
-- Sam Whited sam@samwhited.com