Re: [Standards] XEP-0388 SASL2: #2 Inline features

[Florian Schmaus]

On 19/11/2022 16.16, Dave Cridland wrote:

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor <th...@eightysoft.de <mailto:th...@eightysoft.de>> wrote:

    Again, MattJ already explained this well:
    https://mail.jabber.org/pipermail/
    standards/2022-October/038998.html
    <https://mail.jabber.org/pipermail/standards/2022-October/038998.html>

    SASL2 allows for inlining additional elements into the
    authentication flow.
    That, like pipelining, reduces round-trip-times.
    To let clients distinguish, which features can be inlined into the
    SASL2
    authentication flow and which features are supported by the server
    but can not
    be inlined, a new "namespace" for inlinable features is needed.




    As MattJ says:
     > It's important to stress that, despite calling out XEP-0198 and
    Bind 2
     > in the changelog and text, this is intended for example purposes
    only.
     > There is no intention to increase the scope of XEP-0388 to cover
    which
     > specific protocols can be negotiated (in fact this is the whole
    reason
     > for introducing <inline/> as an extension point).

    The Bind2 update already in our pipeline as well as the XEP-0198
    update use
    that <inline/> element as specified in our SASL2 update.

    In fact, Bind2 has it's own <inline/> element, too.

When I designed SASL2, I designed it such that arbitrary elements could be introduced anywhere in the flow by having them within SASL2 top-level elements. I certainly didn't intend to imply that this meant that clients could inject top-level-elements from other extensions that happened to be supported without negotiation. I'm not sure where that came from. ISR, for example - XEP-0397 - doesn't need the <inline/> element at all to handle XEP-0198. You can argue it's too tied into HT-* or whatever, but the framework for adding extensions into SASL2 exists already and I'm honestly confused as to why a further <inline/> is needed here.

See the previous discussion on <inline/> at

https://mail.jabber.org/pipermail/standards/2022-October/038999.html



1. If we need it twice


For example, a SALS 2 + Bind 2 + FAST auth currently produces this [1]
<stream:features>
  <authentication xmlns="urn:xmpp:sasl:2">
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
    <inline>
      <bind xmlns="urn:xmpp:bind:0">
        <inline>
          <feature var="urn:xmpp:sm:3"/>
          <feature var="urn:xmpp:carbons:2"/>
          <feature var="urn:xmpp:csi:0"/>
        </inline>
      </bind>
      <sm xmlns="urn:xmpp:sm:3"/>
      <fast xmlns="urn:xmpp:fast:0"/>
    </inline>
  </authentication>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
  </mechanisms>
  <sasl-channel-binding xmlns="urn:xmpp:sasl-cb:0">
    <channel-binding type="tls-exporter"/>
  </sasl-channel-binding>
  <register xmlns="urn:xmpp:invite"/>
  <register xmlns="urn:xmpp:ibr-token:0"/>
  <register xmlns="http://jabber.org/features/iq-register"/>
</stream:features>

This is madness, err Sparta.



Why not simply

<stream:features>
  <authentication xmlns="urn:xmpp:sasl:2">
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
    <stream:features xmlns='"jabber:client">
      <bind xmlns="urn:xmpp:bind:0"/>
      <carbons xmlns="urn:xmpp:carbons:2"/>
      <csi xmlns='urn:xmpp:csi:0'/>
      <sm xmlns="urn:xmpp:sm:3"/>
      <fast xmlns="urn:xmpp:fast:0"/>
    </inline>
  </authentication>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
  </mechanisms>
  <sasl-channel-binding xmlns="urn:xmpp:sasl-cb:0">
    <channel-binding type="tls-exporter"/>
  </sasl-channel-binding>
  <register xmlns="urn:xmpp:invite"/>
  <register xmlns="urn:xmpp:ibr-token:0"/>
  <register xmlns="http://jabber.org/features/iq-register"/>
</stream:features>



- Flow

1: https://matthewwild.co.uk/uploads/sasl2-example.xml

I am still not convinced that we need <inline/>, but I urge the authors to at least consider 2. To simply re-use the existing <stream:features> element for that. There is no reason to introduce a new element. First, the <inline> sometimes contains <feature/> var's, and sometimes not. And Stream Management (sm) is there twice. (Yes, I notice that there is no stream feature for carbons, but that shouldn't be a show stopper) from https://mail.jabber.org/pipermail/standards/2022-October/039000.html

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________