Merge branch 'premerge' into 'main'

Premerge

See merge request xsf/xeps!13

xep-0048.xml

@@ -10,7 +10,7 @@
   <abstract>This specification defines an XML data format for use by XMPP clients in storing bookmarks to mult-user chatrooms and web pages. The chatroom bookmarking function includes the ability to auto-join rooms on login.</abstract>
   &LEGALNOTICE;
   <number>0048</number>
-  <status>Draft</status>
+  <status>Deprecated</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <dependencies>
@@ -19,7 +19,9 @@
     <spec>XEP-0223</spec>
   </dependencies>
   <supersedes/>
-  <supersededby/>
+  <supersededby>
+    <spec>XEP-0402</spec>
+  </supersededby>
   <shortname>bookmarks</shortname>
   <schemaloc>
     <url>http://www.xmpp.org/schemas/bookmarks.xsd</url>
@@ -32,6 +34,12 @@
   </author>
   &pgmillard;
   &stpeter;
+  <revision>
+    <version>1.2</version>
+    <date>2020-08-04</date>
+    <initials>XEP Editor (jsc)</initials>
+    <remark>Deprecate in favour of XEP-0402</remark>
+  </revision>
   <revision>
     <version>1.1</version>
     <date>2007-11-07</date>

xep-0313.xml

@@ -28,6 +28,14 @@
   </schemaloc>
   &mwild;
   &ksmith;
+  <revision>
+    <version>0.7.1</version>
+    <date>2020-08-04</date>
+    <initials>rufferson</initials>
+    <remark>
+      <p>Fix missing part of sentence to make more sense</p>
+    </remark>
+  </revision>
   <revision>
     <version>0.7.0</version>
     <date>2020-03-20</date>
@@ -430,7 +438,7 @@
 </iq>
     ]]></example>
 
-      <p>If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields, the server MUST return an item-not-found error in response to the query.</p>
+      <p>If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields is not present in the archive, the server MUST return an item-not-found error in response to the query.</p>
 
     </section3>
     <section3 topic='Retrieving form fields' anchor='query-form'>

xep-0352.xml

@@ -10,7 +10,8 @@
   <abstract>This document defines a way for the client to indicate its active/inactive state.</abstract>
   &LEGALNOTICE;
   <number>0352</number>
-  <status>Deferred</status>
+  <status>Proposed</status>
+  <lastcall>2020-08-18</lastcall>
   <lastcall>2017-12-21</lastcall>
   <lastcall>2017-11-15</lastcall>
   <lastcall>2017-03-28</lastcall>

xep-0411.xml

@@ -10,7 +10,8 @@
   <abstract>This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML.</abstract>
   &LEGALNOTICE;
   <number>0411</number>
-  <status>Deferred</status>
+  <status>Proposed</status>
+  <lastcall>2020-08-18</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>

xep-0440.xml

@@ -23,6 +23,15 @@
   <supersededby/>
   <shortname>sasl-cb-types</shortname>
   &flow;
+  <revision>
+    <version>0.2.0</version>
+    <date>2020-08-04</date>
+    <initials>fs</initials>
+    <remark>
+	  Discuss interaction with SASL mechanism and add security considerations.
+	  Recommend implementation of tls-server-end-point.
+	</remark>
+  </revision>
   <revision>
     <version>0.1.0</version>
     <date>2020-06-14</date>
@@ -88,11 +97,56 @@
 
 </section1>
 
+<section1 topic='Interaction with SASL mechanisms' anchor='sasl-mech-interaction'>
+
+  <p>Some channel-binding enabled SASL mechanisms reflect the server's
+  presumed channel-binding abilities back to the server. This prevents
+  SASL-mechanism stripping attacks, where a Man in the Middle (MITM)
+  removes certain SASL mechanisms in an attempt to downgrade the
+  mechanism choosen for authentication to a non-channel-binding enabled
+  one. An example of a SASL mechanism family with this feature is
+  &rfc5802;. This standard specifies the gs2-cbind-flag. The flag has a
+  tristate value of "I don't support channel-binding" (n), "I think you
+  do not support channel-binding, but I do" (y), or, "Let us use
+  channel-binding type X" (p).</p>
+
+  <p>Clients using the information provided
+  via &lt;sasl-channel-binding/&gt; MAY want to indicate to the server
+  that they do not support channel-binding (even if they do) if no
+  mutual supported channel-binding type was found. The only alternative
+  is, that the client signals the server that he believes that the server
+  does not support channel binding. But this may cause the server to
+  terminate the connection, because it indicates a potential ongoing
+  SASL-mechanism stripping attack.</p>
+
+</section1>
+
 <section1 topic='Security Considerations' anchor='security'>
 
-  <p>The author belives that this document itself does not yield any
+  <p>If a client signals to the server that he does not support
-  new security considerations.<note>Hopefully somebody will correct him, in
+  channel binding, because it found no mutual supported
-  case he is wrong.</note></p>
+  channel-binding types, another MITM attack
+  vector is introduced. An active attacker could replace the
+  &lt;sasl-channel-binding;&gt; list with channel bindings unlikely
+  (or impossible) to be supported by the client. If the client is
+  configured to use non-channel-binding SASL mechanisms as a fallback,
+  this could be used to downgrade the connection security. Note that
+  this attack is a different one than the SASL-mechanism stripping one:
+  Here the attacker tempers with the announced channel-binding types,
+  i.e., the values within &lt;sasl-channel-binding;&gt;</p>
+
+  <p>Depending on the application's security policy, clients may
+  refrain from falling back to non-channel-binding SASL mechanisms
+  if no mutual supported channel-binding type is available.
+  Alternatively, they may try channel-binding with a supported type
+  nevertheless. To mitigate the attack describe above, clients
+  could "pin" the announced channel bindings types by a service. In that
+  case, implementations may want to allow the set of pinned channel-binding
+  types to be extended to stronger ones.</p>
+
+  <p>As further mitigation, it is RECOMMENDED to implement the
+  channel-binding type tls-server-end-point (&rfc5929;) to increase the
+  probability of a mutual supported channel-binding type.</p>
 
 </section1>
 
@@ -117,7 +171,10 @@
 <section1 topic='Acknowledgements' anchor='acknowledgements'>
 
   <p>Thanks to Sam Whited for the discussion about the underlying
-  issue and incentivizing me to come up with this extension.</p>
+  issue and incentivizing me to come up with this extension. Further
+  thanks goes to Ruslan N. Marchenko for pointing out the possible
+  MITM attack vector. Last but not least, Dave Cridland provided
+  valuable feedback.</p>
 
 </section1>