xeps/inbox/isr-sasl2.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
  <!ENTITY tls13 "<span class='ref'><link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-19'>draft-ietf-tls-tls13-19</link></span> <note>The Transport Layer Security (TLS) Protocol Version 1.3 &lt;<link url='https://tools.ietf.org/html/draft-ietf-tls-tls13-19'>https://tools.ietf.org/html/draft-ietf-tls-tls13-19</link>&gt;.</note>" >
  <!ENTITY iana-hash-alg "<span class='ref'><link url='https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg'>IANA Named Information Hash Algorithm Registry</link></span><note>IANA Named Information Hash Algorithm Registry &lt;<link url='https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg'>https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg</link>&gt;.</note>" >
  <!ENTITY iana-cbt "<span class='ref'><link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>IANA Channel-Binding Types</link></span><note>IANA Channel-Binding Types&lt;<link url='https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml'>https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml</link>&gt;.</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Instant Stream Resumption</title>

  <abstract>This specification introduces a mechanism for instant
  stream resumption, based on Stream Management (XEP-0198), allowing
  XMPP entities to instantaneously resume an XMPP stream.</abstract>

  <legal>
    <copyright>This XMPP Extension Protocol is copyright (c) 1999 -
    2016 by the XMPP Standards Foundation (XSF).</copyright>

  <permissions>Permission is hereby granted, free of charge, to any
    person obtaining a copy of this specification (the
    &quot;Specification&quot;), to make use of the Specification
    without restriction, including without limitation the rights to
    implement the Specification in a software program, deploy the
    Specification in a network service, and copy, modify, merge,
    publish, translate, distribute, sublicense, or sell copies of the
    Specification, and to permit persons to whom the Specification is
    furnished to do so, subject to the condition that the foregoing
    copyright notice and this permission notice shall be included in
    all copies or substantial portions of the Specification. Unless
    separate permission is granted, modified works that are
    redistributed shall not contain misleading information regarding
    the authors, title, number, or publisher of the Specification, and
    shall not claim endorsement of the modified works by the authors,
    any organization or project to which the authors belong, or the
    XMPP Standards Foundation.</permissions>

  <warranty>## NOTE WELL: This Specification is provided on an
    &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, express or implied, including, without limitation, any
    warranties or conditions of TITLE, NON-INFRINGEMENT,
    MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event
    shall the XMPP Standards Foundation or the authors of this
    Specification be liable for any claim, damages, or other
    liability, whether in an action of contract, tort, or otherwise,
    arising from, out of, or in connection with the Specification or
    the implementation, deployment, or other use of the
    Specification. ##</warranty>

  <liability>In no event and under no legal theory, whether in tort
    (including negligence), contract, or otherwise, unless required by
    applicable law (such as deliberate and grossly negligent acts) or
    agreed to in writing, shall the XMPP Standards Foundation or any
    author of this Specification be liable for damages, including any
    direct, indirect, special, incidental, or consequential damages of
    any character arising out of the use or inability to use the
    Specification (including but not limited to damages for loss of
    goodwill, work stoppage, computer failure or malfunction, or any
    and all other commercial damages or losses), even if the XMPP
    Standards Foundation or such author has been advised of the
    possibility of such damages.</liability>

  <conformance>This XMPP Extension Protocol has been contributed in
    full conformance with the XSF's Intellectual Property Rights
    Policy (a copy of which may be found at &lt;<link
      url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt;
    or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201
    USA).</conformance>
  </legal>

  <number>xxxx</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0198</spec>
    <spec>XEP-0388</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>isr</shortname>
  <author>
    <firstname>Florian</firstname>
    <surname>Schmaus</surname>
    <email>flo@geekplace.eu</email>
    <jid>flo@geekplace.eu</jid>
  </author>
  <revision>
    <version>0.0.3</version>
    <date>2017-03-17</date>
    <initials>fs</initials>
    <remark><p>Based ISR on SASL2.</p></remark>
  </revision>
  <revision>
    <version>0.0.2</version>
    <date>2016-03-11</date>
    <initials>fs</initials>
    <remark><p>Second draft.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2016-02-12</date>
    <initials>fs</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>

  <p>This XEP specifies an instant stream resumption mechanism based
  on &xep0198;, allowing XMPP entities to instantaneously resume an
  XMPP stream. This can be seen as the complementary part to &xep0305;
  allowing for fast XMPP session (re-)establishment.</p>

  <p>Compared to the existing stream resumption mechanism of <link
  url='http://xmpp.org/extensions/xep-0198.html#resumption'><cite>XEP-0198</cite>
  § 5</link>, the approach defined herein reduces the round trips
  required to resume a stream to exactly <em>one</em>. This is
  achieved by using just a secure short-lived key to resume the
  stream.</p>

</section1>

<section1 topic='Glossary' anchor='glossary'>

  <dl>
  <di>
    <dt>ISR</dt>
    <dd>Instant Stream Resumption.</dd>
  </di>
  <di>
    <dt>Instant Stream Resumption Key (ISR Key)</dt>
    <dd>A shared secret that is exclusively ephemeral and represented as string.</dd>
  </di>
  <di>
    <dt>TLS</dt>
    <dd>Transport Layer Security (&rfc5246;).</dd>
  </di>
  </dl>

</section1>

<!--
<section1 topic='Use Cases' anchor='usecases'>
  <p>STRONGLY RECOMMENDED.</p>
</section1>
-->

<section1 topic='Stream Feature'>

  <p>XMPP entities providing Instant Stream Resumption MUST announce
  that functionality as stream feature, but only if an instant stream
  resumption is possible at this stage. The ISR stream future consists
  of an &lt;isr/&gt; element qualified by the 'urn:xmpp:isr:0'
  namespace. And since ISR requires TLS, this means that the
  &lt;isr/&gt; stream feature only appears on TLS secured
  connections.</p>

  <p>The ISR stream feature element MUST contain a &lt;mechanisms/&gt;
  element as defined in &rfc6120;. This element contains the SASL
  mechanism which are available to be used for instant stream
  resumption.</p>

  <example caption='Server announces the Instant Stream Resumption Stream Feature'><![CDATA[
<stream:stream
  from='example.com'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/stream'
  version='1.0'>

<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <sm xmlns='urn:xmpp:sm:3'/>
  <isr xmlns='urn:xmpp:isr:0'>
    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
      <mechanism>X-HT-SHA-256-ENDP</mechanism>
    </mechaisms>
  </isr>
</stream:features>
]]></example>

  <p>Every ISR enabled entity MUST support the X-HT-SHA-256-ENDP
  mechanism, support for X-HT-SHA-256-UNIQ is RECOMMENDED. The family
  of SASL <cite>X-HT-*</cite> mechanisms is defined below in <link
  url='#ht-sasl'>Section 6</link>.</p>

</section1>

<section1 topic='Obtaining a Instant Stream Resumption Key' anchor='obtain'>

  <p>In order to obtain an ISR key, the requesting entity must add a
  'mechanism' attribute qualified by the 'urn:xmpp:isr:0' namespace to
  the &lt;enable/&gt; element as defined in &xep0198; when attempting
  to enable Stream Management. The value of the 'mechanism' attribute
  is the name of the SASL mechanism the requesting entity will use
  when performing ISR with the returned key. The entities involved in
  ISR MUST only use or allow this mechanism when performing ISR with
  the according key. This effectively pins the SASL
  mechanism <note>Pinning the SASL mechanism is believed to
  increase the security</note>.</p>

  <example caption='An &lt;enable/gt; Nonza with the ISR &apos;mechanism&apos; attribute'><![CDATA[
<enable
  xmlns='urn:xmpp:sm:3'
  xmlns:isr='urn:xmpp:isr:0'
  isr:mechanism='X-HT-SHA-256-ENDP'/>
]]></example>

  <p>Next, the &lt;enabled/&gt; Nonza (see &xep0360;) which is send as
  positive reply upon a request to enable Stream Management, MUST
  contain an 'key' attribute qualified by the 'urn:xmpp:isr:0'
  namespace containing a ISR key. The key MUST be newly generated by a
  cryptographically secure random number generator and MUST contain at
  lest 128 bit of entropy. The Nonza can optionally also contain a
  'location' attribute qualified by the 'urn:xmpp:isr:0' namespace
  which specifies the preferred IP address or hostname, and a TCP port
  number of the host which should be used for instant stream
  resumption.</p>

  <example caption='An &lt;enabled/&gt; Nonza with a ISR key'><![CDATA[
<enabled
  xmlns='urn:xmpp:sm:3'
  xmlns:isr='urn:xmpp:isr:0'
  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>]]></example>

  <example caption='An &lt;enabled/&gt; Nonza with a ISR key and location'><![CDATA[
<enabled
  xmlns='urn:xmpp:sm:3'
  xmlns:isr='urn:xmpp:isr:0'
  isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'
  isr:location='isr.example.org:5222'/>]]></example>

  <p>The &lt;enabled/&gt; Nonza containing an ISR key MUST only be
  sent over TLS secured connections.</p>

</section1>

<section1 topic='Instant Stream Resumption' anchor='isr'>

  <p>In order to instantaneously resume an XMPP stream the initiating
  entity, which is either an XMPP client or server, must posses a
  valid ISR key. After it has obtained the ISR key, using the process
  described in the previous section, it first determines the host for
  resumption, and after that, tries to perform the instant stream
  resumption.</p>

  <section2 topic='Determing the Host for Resumption' anchor='host'>

  <p>The lookup mechanism order to determine host candidates for ISR
  resumption is as follows:</p>

  <ol>
    <li>The host provided in the optional 'location' attribute
    qualified by the 'urn:xmpp:isr:0' namespace found in the
    &lt;enabled/&gt; element of <cite>XEP-0198</cite> (the
    "isr:location").
    </li>
    <li>The hosts determined by means of &xep0368;.</li>
    <li>The host announced in the 'location' attribute of the
    &lt;enabled/&gt; Nonza defined in <cite>XEP-0198</cite>.</li>
    <li>Standard host lookup mechanisms.</li>
  </ol>

  <p>The host candidates retrieved by those mechanisms SHOULD be
  tried by the initiating entity in this order.</p>

  <p>Note that the hosts announced by the 'location' attribute
  qualified by the 'urn:xmpp:isr:0' namespace MUST be connected to
  using TLS from the beginning, i.e. &lt;starttls/&gt; MUST NOT be
  used, instead the TLS handshake is performed right after
  establishing the connection.</p>

  <p>This order prefers hosts which allow connections where TLS is
  enabled from the beginning. This is desirable to reduce the
  required round trips by skipping the &lt;starttls/&gt; step.</p>

  </section2>

  <section2 topic='Performing Instant Stream Resumption' anchor='resume'>

  <p>After the remote host on which the instant stream resumption
  should be performed was determined, the initiating entity connects
  to the host, and establishes TLS by either</p>

  <ol>
    <li>establishing a TLS session right away, or</li>
    <li>performing STARTTLS (&rfc6120; § 5).</li>
  </ol>

  <p>Now the initiating entity sends an XMPP &lt;stream&gt; open
  element followed by a &lt;authenticate/&gt; Nonza as specified in
  the &xep0388;. The initiating entity must also provide a
  &lt;inst-resume/&gt; element qualified by the 'urn:xmpp:isr:0'
  namespace, which must contain a &lt;resume/&gt; element as defined
  in &xep0198;.</p>

  <p>If the 'without-isr-token' attribute is set to true, then the
  SASL mechanisms are performed as when traditionally authenticating
  the XMPP session. If the value of the attribute is 'false', which is
  the default value for this attribute, then the "password" given to
  the SASL mechanism is the ISR key. Note that this implies that only
  SASL mechanisms which take a password/token can be used this
  way.</p>

  <p>All ISR implementations MUST support the
  X-HT-SHA-256-ENDP mechanism.</p>

  <example caption='Initiating entity requests instant stream resumption via the Extensible SASL Profile (XEP-0388)'><![CDATA[
<?xml version='1.0'?>
<stream:stream
    from='juliet@im.example.com'
    to='im.example.com'
    version='1.0'
    xml:lang='en'
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'>

<authenticate xmlns='urn:xmpp:sasl:0' mechanism='X-HT-SHA-256-ENDP'>
  <initial-response></initial-response>
  <inst-resume xmlns='urn:xmpp:isr:0' without-isr-token='false'/>
    <resume xmlns='urn:xmpp:sm:3'
            h='some-sequence-number'
            previd='some-long-sm-id'/>
  </inst-resume>
</authenticate>
]]></example>

    <p>Note that the initiating entity SHOULD pipeline the instant
  stream resumption request together with then initial
  &lt;stream&gt; open element. The initiating entity is able to do
  so since it already knows that the service supports ISR because it
  announced an ISR key.</p>

  <p>Servers MUST destroy the ISR key of a stream after an instant
  stream resumption was attempted for that stream with an invalid ISR
  key. Server implementations MUST implement the ISR key comparision in
  linear runtime.</p>

  <section3 topic='Successful Stream Resumption' anchor='isr-success'>

  <example caption='Successful Instant Stream Resumption'><![CDATA[
<success xmlns='urn:xmpp:sasl:0'>z
  <success-data></success-data>
  <inst-resumed xmlns='urn:xmpp:isr:o'
                key='006b1a29-c549-41c7-a12c-2a931822f8c0'>
    <resumed xmlns='urn:xmpp:sm:3' h='354' previd='123'/>
  </inst-resumed>
</success>
]]></example>

  <p>On success the server replies with a &lt;success/&gt; nonza as
  specified in the &xep0388;, which must include a
  &lt;inst-resumed/&gt; element qualified by the 'urn:xmpp:isr:0'
  namespace. This element MUST contain a <em>new</em> ISR Key found in
  the 'key' attribute. It also MUST include a &lt;resumed/&gt; as
  specified in &xep0198; containing the sequence number of the last by
  Stream Management handled stanza in the 'h' attribute and the
  'previd' attribute.</p>

  <p>In case of an successful Instant Stream Resumption authenticated
  by an ISR key, the server MUST immediately destroy the ISR key after
  authentication, i.e., it MUST no longer be possible to perform an
  ISR using that ISR key and Stream Management ID (SM-ID, see
  &xep0198;) tuple.</p>

  <p>After the &lt;inst-resumed/&gt; was received and has been
  verified both entities MUST consider the resumed stream to be
  re-established. This includes all previously negotiated stream
  features like &xep0138;. It does however not include the specific
  state of the features: For example in case of Stream Compression,
  the dictionary used by the compression mechanism of the resumed
  stream MUST NOT be considered to be restored after instant stream
  resumption.</p>

  <p class='box'>Note that this behavior is different from &xep0198;
  stream resumption, where "outer stream" features like compression
  are not restored. Since such a behavior would be counterproductive
  towards the goal of this XEP, it specifies that the negotiation
  state of such "outer stream" features is also restored (besides the
  features which where already negotiated at ISR-time, i.e. TLS).</p>

  </section3>

    <section3 topic='Successful Authentication but failed Stream Resumption' anchor='isr-auth-success-resumption-failed'>

    <p>If the server was able to authenticate the initiating entity
    but is unable to resume the stream instantly it MUST reply with a
    &lt;success/&gt; Nonza as defined in the &xep0388; containing
    a &lt;inst-resume-failed/&gt; element qualified by the
    'urn:xmpp:isr:0' namespace. This
    &lt;inst-resume-failed/&gt; MUST contain a &lt;failed/&gt;
    element as defined in &xep0198;.</p>

    <example caption='Server indicates instant stream resumption failure'><![CDATA[
<success xmlns='urn:xmpp:sasl:0'>
  <inst-resume-failed xmlns='urn:xmpp:isr:0'>
    <failed xmlns='urn:xmpp:sm:3'
            h='another-sequence-number'>
      <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    </failed>
  </inst-resume-failed>
</sucess>
]]></example>

    <p>Instant stream resumption errors SHOULD be considered
    recoverable, the initiating entity MAY continue with normal
    session establishment; however, misuse of stream management MAY
    result in termination of the stream. Since the initiating entity is
    authenticated, it could continue with resource binding by using
    &rfc6120; § 7. or &xep0386;.</p>

  </section3>

  <section3 topic='Multi SASL Mechanism ISR' anchor='multi-sasl-mech-isr'>

    <p>As specified in the &xep0388; § 2.6.4, a single SASL
    mechanism may not be sufficient for authentication. In this case,
    the remote entity sends a &lt;continue/&gt; element as defined in
    &xep0388; to request the local entity to perform another
    SASL mechanism. Performing instant stream resumption using
    multiple SASL mechanisms MUST only be done if the
    'without-isr-token' attribute is set to 'true'.</p>

    <example caption='Server requires Multi SASL Mechanism ISR'><![CDATA[
<continue xmlns='urn:xmpp:sasl:0'>
  <additional-data>
   T3B0aW9uYWwgQmFzZSA2NCBlbmNvZGVkIFNBU0wgc3VjY2VzcyBkYXRh
  </additional-data>
  <mechanisms>
    <mechanism>HOTP-EXAMPLE</mechanism>
    <mechanism>TOTP-EXAMPLE</mechanism>
  <mechanisms>
</continue>
]]></example>

  </section3>

    <section3 topic='Failed ISR Authentication' anchor='isr-auth-failed'>

    <p>If the server is unable to authenticate the initiating entity it
    MUST reply with a &lt;failure/&gt; Nonza as defined in
    &xep0388;.</p>

    <example caption='Server indicates instant stream resumption failure'><![CDATA[
<failure xmlns='urn:xmpp:sasl:0'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</failure>
]]></example>

    <p>After the ISR authentication has failed, the initiating entity
    could continue with normal authentication (&xep0388;,
    …).</p>

  </section3>

  </section2>

</section1>

<section1 topic='The X-HT-* SASL Mechanism' anchor='ht-sasl'>

  <p>This section specifies the Hashed Token (X-HT-*) SASL
  mechanism. This mechanism was designed to be used with short-lived
  tokens (shared secrets) for authentication. It provides hash
  agility, mutual authentication and is secured by channel
  binding. Since the token is not salted, and only one iteration is
  used, the X-HT mechanism is not suitable to protect long-lived
  shared secrets (e.g. "passwords"). You may want to look at &rfc5802;
  for that.</p>

  <section2 topic='The X-HT-* Family of Mechanisms' anchor='ht-sasl-mechanism-family'>

    <p>Each mechanism in this family differs by the choice of the hash
    algorithm and the choice of the channel binding type. Each
    mechanism has a name of the form X-HT-[HA]-[CBT] where [HA] is the
    "Hash Name String" of the &iana-hash-alg; registry in capital
    letters, and [CBT] is one of 'ENDP' or 'UNIQ'. In case of 'ENDP',
    the tls-server-end-point channel binding type is used. In case of
    'UNIQ', the tls-unique channel binding type is used. For more
    information about channel binding, see &rfc5929; and the
    &iana-cbt; registry.</p>

    <table caption='Mapping of CBT to Channel Bindings'>
      <tr><th>CBT</th><th>Channel Binding Type</th></tr>
      <tr><td>ENDP</td><td>tls-server-end-point</td></tr>
      <tr><td>UNIQ</td><td>tls-unique</td></tr>
    </table>

    <p>The following table lists a few examples of X-HT-* SASL
    mechanism names.</p>

    <table caption='Example X-HT-* SASL mechanisms'>
      <tr><th>Mechanism Name</th><th>Hash Algorithm</th><th>Channel-binding unique prefix</th></tr>
      <tr><td>X-HT-SHA-512-ENDP</td><td>SHA-512 (FIPS 180-4)</td><td>tls-server-end-point</td></tr>
      <tr><td>X-HT-SHA3-256-ENDP</td><td>SHA3-512 (FIPS 202)</td><td>tls-server-end-point</td></tr>
      <tr><td>X-HT-SHA-512-UNIQ</td><td>SHA-512 (FIPS 180-4)</td><td>tls-unique</td></tr>
      <tr><td>X-HT-SHA-256-UNIQ</td><td>SHA-256 (&rfc6920;)</td><td>tls-unique</td></tr>
    </table>
  </section2>

  <section2 topic='The X-HT Mechanism' anchor='ht-sasl-mechanism'>

    <p>The mechanism consists of a simple exchange of exactly two
    messages between the initiator and responder. It starts with the
    message from the initiator to the responder. This
    'initiator-message' is defined as follows:</p>

    <p class='box'>
      initiator-message = HMAC(token, "Initiator" || cb-data)
    </p>

    <p>HMAC() is the function defined in &rfc2104; with H being the
    chosen hash algorithm, 'cb-data' represents channel binding type
    data, and 'token' are the UTF-8 (see &rfc3629;) encoded bytes of
    the token String which acts as shared secret between initiator and
    responder.  The initiator-message MUST NOT be included in TLS 1.3
    0-RTT early data (&tls13;).</p>

    <p>This message is followed by a message from the responder to the
    initiator. This 'responder-message' is defined as follows:</p>

    <p class='box'>
      responder-message = HMAC(token, "Responder" || cb-data)
    </p>

    <p>The initiating entity MUST verify the responder-message to
    achieve mutual authentication.</p>

  </section2>

  <section2 topic='Security Considerations for the X-HT SASL Mechanism' anchor='ht-sasl-security-considerations'>

    <p>To be secure, X-HT MUST be used over a TLS channel that has had
    the session hash extension &rfc7627; negotiated, or session
    resumption MUST NOT have been used.</p>

  </section2>

</section1>

<section1 topic='Security Considerations' anchor='security'>

  <p>Putting ISR data in <cite>TLS 1.3</cite> 0-RTT early data is
  forbidden. (TODO: Shall we weaken this requirement to allow early
  data?. It would be technically possible if the sender does not add
  additional data, for example Stanzas, after the ISR/XEP-0388 data at
  the end of the early data. And if the receiver does ensure that the
  existence of such additional data is causing an ISR failure.)</p>

  <p>It is of vital importance that the Instant Stream Resumption Key
  is generated by a cryptographically secure random generator. See
  &rfc4086; for more information about Randomness Requirements for
  Security</p>

</section1>

<section1 topic='IANA Considerations' anchor='iana'>

  <p>This document requires no interaction with &IANA;.</p>

</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>

  <p>The &REGISTRAR; includes 'urn:xmpp:isr:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>

</section1>

<section1 topic='XML Schema' anchor='schema'>

  <p>TODO: Add after the XEP leaves the 'experimental' state.</p>

</section1>

<section1 topic='Acknowledgements' anchor='acknowledgements'>

  <p>Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland,
  Maxime Buquet and Alexander Würstlein for their feedback.</p>

</section1>

</xep>