moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-20 22:58:52 -05:00
Code Issues Releases Wiki Activity

Merge branch 'merge/xep-0368'

Browse Source
This commit is contained in:
Jonas Schäfer 2019-08-20 18:19:01 +02:00
commit 404718b64a
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
xep-0368.xml
View File

@ -29,6 +29,12 @@
<email>travis@burtrum.org</email>
<jid>travis@burtrum.org</jid>
</author>
<revision>
<version>1.1.0</version>
<date>2019-08-20</date>
<initials>jsc</initials>
<remark><p>Describe how to fall back if _xmpps-server/_xmpps-client records cannot be found.</p></remark>
</revision>
<revision>
<version>1.0.1</version>
<date>2019-07-15</date>
@ -109,6 +115,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>
</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>