Am 08.04.2013 18:45, schrieb Philipp Hancke:
Am 19.03.2013 02:49, schrieb Kim Alvefur:
4. Do you have any security concerns related to this specification?
The elevation of any method of domain spoofing to also include possible
interception of outgoing stanzas. Mistakes by, or compromise of a CA,
faulty certificate validation etc might make it possible to do a MITM
without needing to do anything DNS related.
[...]
Does the following paragraph address this? "compromised" is vage on
purpose, thanks Dave.
Note that bidirectionality may broaden the impact of an attack that
allows spoofing of XMPP stanzas (such as the "unsolicited server
dialback" attack described in XEP-0220 or the usage of compromised
certificates) by delivering stanzas to the wrong target.
Patch attached, thanks zash.
diff --git a/extensions/xep-0288.xml b/extensions/xep-0288.xml
index 293f96f..52b578a 100755
--- a/extensions/xep-0288.xml
+++ b/extensions/xep-0288.xml
@@ -34,6 +34,12 @@
<jid>dave.cridl...@isode.com</jid>
</author>
<revision>
+ <version>0.5</version>
+ <date>2012-08-10</date>
+ <initials>ph/dwd</initials>
+ <remark><p>Additional security considerations about the "unsolicited dialback" attack on bidirectional connection.</p></remark>
+ </revision>
+ <revision>
<version>0.4</version>
<date>2012-07-23</date>
<initials>ph</initials>
@@ -212,7 +218,7 @@ C: <db:result from='capulet.lit' to='conference.montague.lit' type='valid'/>
<section1 topic='Security Considerations' anchor='security'>
<p>This specification introduces no security considerations above and beyond those discussed in <cite>RFC 6120</cite> or <cite>XEP-0220</cite>.
<!-- one might explain why not... http://mail.jabber.org/pipermail/xmppwg/2004-February/002026.html -->
- Note that when using Server Dialback, a server must be very careful when receiving a <db:result/> of type 'valid' without having sent a corresponding request to add the domain pair given by the 'from' and 'to' attributes. In particular it MUST NOT route stanzas to the domain given in the elements 'from' attribute over this XML stream without further proof of the peers identity.</p>
+ Note that the impact of the "unsolicited server dialback" attack described in <cite>XEP-0220</cite> is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a "type" attribute also need to be handled in incoming connections.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
