moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

XEP-0344 v0.2: Editorial fixes

Browse Source
This commit is contained in:
Matthew A. Miller 2014-03-19 11:23:57 -06:00
parent e45de052af
commit b6412a448d
1 changed files with 11 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0344.xml
View File

@ -21,6 +21,14 @@
<supersedes/>
<supersededby/>
<shortname>dwd</shortname>
<revision>
<version>0.2</version>
<date>2014-03-19</date>
<initials>editor (mam)</initials>
<remark>
<p>Editorial fixes.</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2014-03-14</date>
@ -296,13 +304,13 @@ example example
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>With respect to <strong>XEP-0220</strong>'s security considerations, the adaptations in this document add at minimum channel encryption and integrity, which forces an attacker into making an active attack, rather than passive eavesdropping. This raises the cost of an attack significantly. However, unless the certificates are authenticated, there is still a man-in-the-middle attack possible, and the reliance on unauthenticated DNS remains problematic.</p>
<section2 title='Same Certificate shortcut'>
<section2 topic='Same Certificate shortcut'>
<p>Use of the "Same Certificate" shortcut described in XXXX is not thought to materially alter the security profile beyond that described above. In particular, it does not alter the level of trust an implementation may put in authentication.</p>
</section2>
<section2 title='Dialback without dialback shortcut'>
<section2 topic='Dialback without dialback shortcut'>
<p>Use of the "Dialback without dialback" shortcut described in XXXX raises the level of authentication to that of the TLS/SASL-EXTERNAL process described in <strong>RFC 6120</strong>, and is thought to be indistinguishable from a security standpoint. As such, the security considerations relating to this in <strong>RFC 6120</strong> et al apply.</p>
</section2>
<section2 title="DNSSEC">
<section2 topic="DNSSEC">
<p>If both SRV and A/AAAA records are protected by DNSSEC, this means that the correct address for the peer can be proven, removing DNS forgery as an attack vector. Without TLS, it is however still possible to mount an array of attacks, including IP spoofing and eavesdropping.</p>
<p>With TLS, however, the situation improves. Since TLS protects against a naïve IP spoofing attack, a routing protocol attack (such as BGP hijacking) is required to forge the server.</p>
</section2>