0.5

xep-0288.xml

@@ -33,6 +33,12 @@
     <email>dave.cridland@isode.com</email>
     <jid>dave.cridland@isode.com</jid>
   </author>
+  <revision>
+    <version>0.5</version>
+    <date>2012-08-21</date>
+    <initials>ph/dwd</initials>
+    <remark><p>Defined additional security considerations about the &quot;unsolicited dialback&quot; attack on bidirectional connections.</p></remark>
+  </revision>
   <revision>
     <version>0.4</version>
     <date>2012-07-23</date>
@@ -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 &lt;db:result/&gt; 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 &quot;unsolicited server dialback&quot; 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 &quot;type&quot; 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'>