Hi all, I have not been able to find proper SRV record fallback behavior documented, and could not come to a clear consensus in the XSF MUC earlier, so I thought I'd bring the discussion on-list. (and hopefully document it in implementation notes of XEP-0368[1])
The main question is when you should fall back to lower priority SRV records and when should you give up and fail the connection. First, what do docs say: RFC-6120[2] Section-3.2.1 #7 says: > 7. If the initiating entity fails to connect using all resolved IP > addresses for a given FDQN, then it repeats the process of > resolution and connection for the next FQDN returned by the SRV > lookup based on the priority and weight as defined in [DNS-SRV]. 'fails to connect' does this mean the TCP connection fails, or the XMPP connection fails? #8 might leave a hint: > 8. If the initiating entity receives a response to its SRV query but > it is not able to establish an XMPP connection using the data > received in the response, it SHOULD NOT attempt the fallback > process described in the next section (this helps to prevent a > state mismatch between inbound and outbound connections). This clearly says XMPP connection, but does it apply to #7 ? It is also clear I didn't think about this too hard when writing XEP-0368, because I clearly (to me) assume SRV fallback will happen if a complete XMPP connection is not successful, because under Implementation Notes I say: > Server operators should not expect multiplexing (via ALPN) to work in > all scenarios and therefore should provide additional SRV record(s) > that do not require multiplexing (either standard STARTTLS or > dedicated direct XMPP-over-TLS). This is a result of relying on ALPN > for multiplexing, where ALPN might not be supported by all devices or > may be disabled by a user due to privacy reasons. While I don't explicitly say it, if a port required ALPN to multiplex, it will generally end up connecting you to a non-XMPP server without ALPN, meaning you will get back invalid XML, other junk, and/or an invalid TLS cert. RFC-2782[3], defining SRV records, makes no mention of this. Which actually makes sense because it doesn't even define possible protocols, UDP for example has no connection concept. Now that the docs are out of the way, on to the discussion: In my opinion, at least all of cannot-connect-to-port, non-XML, not-proper-stream and invalid TLS cert should trigger a fallback to the next highest priority SRV record. Everyone in the MUC seemed to agree if authentication fails a fallback would be a bad idea. Sam Whited said that if a TCP connection is established fallback should cease, that it shouldn't have anything to do with or any knowledge of XMPP, and that it might have security implementations to do otherwise. (please correct and forgive me if I misunderstood) I disagree with this, I think if Eve has control over DNS (and no DNSSEC) she can return arbitrary records anyway so SRV fallback doesn't matter. If Eve controls a higher priority server, or the network between client and that server, she can trigger fallback or not regardless of what we decide. The difference is if we decide not to fallback, then she can effectively DOS us by messing with 1 server instead of all. I think my proposal is even more generic than the above, I think authentication-response should be the point when fallback ceases. Regardless of what happens before that point, you fall back to the next SRV record, and after authentication, whether it's successful or not, you no longer fall back anymore. As to what actual clients do in the wild, Conversations falls back regardless of junk or invalid cert, dino does not. I am unsure what gajim does (though from talking to lovetox 1.0-beta might also not fallback in all cases). Depending what we decide, I plan to set up various domain/SRV record combinations for testing, probably clients and servers both need this type of testing, and I doubt it is done often. Thanks, Travis [1]: https://xmpp.org/extensions/xep-0368.html [2]: https://tools.ietf.org/html/rfc6120#section-3.2.1 [3]: https://tools.ietf.org/html/rfc2782 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
