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 [email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
--
Sam Whited
[email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
