moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 09:42:20 -05:00
Code Issues Releases Wiki Activity

XEP-0368: clarify fallback behavior on SRV failure

Browse Source
This commit is contained in:
Travis Burtrum 2019-07-19 01:30:25 -04:00
parent b5e93e8e57
commit bdf4551cf2
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0368.xml
View File

@ -103,7 +103,7 @@
<section1 topic='Implementation Notes' anchor='impl'>
<p>The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for direct TLS.</p>
<p>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.</p>
<p>If the <tt>_xmpps-client</tt> (or <tt>_xmpps-server</tt>) target is set to <tt>.</tt> (dot), this indicates as per &rfc2782; that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up <tt>_xmpp-client</tt> (or <tt>_xmpp-server</tt>) records. The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).</p>
<p>If the <tt>_xmpps-client</tt> (or <tt>_xmpps-server</tt>) target is set to <tt>.</tt> (dot), this indicates as per &rfc2782; that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up <tt>_xmpp-client</tt> (or <tt>_xmpp-server</tt>) records. If the initiating party cannot connect via either SRV record, it SHOULD perform A/AAAA fallback to port(s) of it's choice (perhaps 443, 5223, etc) because, in the absence of DNSSEC, SRV records cannot be trusted.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Direct TLS provides AT LEAST the same level of security as STARTTLS, and more privacy without ALPN as using STARTTLS leaks that the underlying protocol is XMPP, while any direct TLS stream should be indistinguishable from any other direct TLS stream. Direct TLS provides more security than STARTTLS if &rfc7590; is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the STARTTLS and direct TLS logic as well. All SRV-based connection methods are subject to DNS modification/stripping/spoofing of SRV records in the absence of DNSSEC.</p>