[kitten] Re: [Standards] Re: draft-ietf-kitten-sasl-ht -01 uploaded

--===============8315767032205781456==
Content-Type: multipart/alternative; boundary="000000000000c21ad20654d3ad12"

--000000000000c21ad20654d3ad12
Content-Type: text/plain; charset="UTF-8"

I note that FAST introduces an external (to HT-*) counter as a replay
protection. This feels like a layer violation, in as much as replay
protection feels like it's a concern of the SASL mechanism.

Previous attempts to get a mechanism with a coordinated counter through
this working group were tricky, Chris Newman observed that for many
distributed systems this was complex. Examples given were email clients
simultaneously connecting to IMAP and Submission, and read-only LDAP
"mirror" servers. (See
https://datatracker.ietf.org/doc/html/draft-cridland-kitten-clientkey-00
for the design I abandoned in favour of HT-* for mostly this reason).

So, question:

Do we want to put a replay counter into HT2-*?

(I'll send a follow-up to [email protected] concerning the 0-RTT replay
case specifically)

Dave.

On Mon, 22 Jun 2026 at 09:09, Florian Schmaus <[email protected]> wrote:

> On 12/05/2026 13.28, Florian Schmaus wrote:
> > I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the
> > adoption by the Kitten WG are
> >
> > - the introduction of a response status byte to indicate success or
> >    failure responses
> > - the capability to transmit authenticated key/value pairs in the
> >    exchanged messages (e.g., for XEP-0474 [1])
> >
> >
> > SASL-HT is already deployed using an older and incompatible version of
> > the I-D in some parts of the XMPP ecosystem. Therefore, we probably need
> > to adjust the SASL Mechanism Name to avoid interoperability issues. For
> > example, from
> >
> > HT-SHA-512-ENDP
> >
> > to
> >
> > HT2-SHA-512-ENDP
> >
> > Please forgive my lack of creativity regarding the new name. Suggestions
> > on a more creative naming schema that is in-line with the constraints of
> > SASL Mechanism names are appreciated.
> >
> > And, of course, feedback in general is welcomed.
> I am going to ask the Kitten WG chair to initiate the next step for
> SASL-HT this week. Therefore, *now* would be a good time for feedback.
>
> FAST (XEP-0484) is currently using draft-schmaus-kitten-sasl-ht-09. The
> diff between this version and the lastest can be viewed via
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-schmaus-kitten-sasl-ht-09&url2=draft-ietf-kitten-sasl-ht-02&difftype=--html
>
> The latest version of sasl-ht uses the HT2-* prefix for its SASl
> mechanism name, instead of the HT-* prefix used by version -09. This
> name adjustment was necessary because the wire protocol changed
> slightly. It is perfectly fine for XEP FAST to continue using -09.
> Support for HT2-*, and its advantages, like support for SASL downgrade
> protection, can be deployed alongside it a later time (and shouldn't
> require any changes to XEP FAST).
>
> - Flow
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--000000000000c21ad20654d3ad12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I note that FAST introduces an external (to HT-*) counter =
as a replay protection. This feels like a layer violation, in as much as re=
play protection feels like it&#39;s a concern of the SASL mechanism.<div><b=
r></div><div>Previous attempts to get a mechanism with a coordinated counte=
r through this working group were tricky, Chris Newman observed that for ma=
ny distributed systems this was complex.=C2=A0Examples given were email cli=
ents simultaneously connecting to IMAP and Submission, and read-only LDAP &=
quot;mirror&quot; servers. (See=C2=A0<a href=3D"https://datatracker.ietf.or=
g/doc/html/draft-cridland-kitten-clientkey-00">https://datatracker.ietf.org=
/doc/html/draft-cridland-kitten-clientkey-00</a> for the design I abandoned=
 in favour of HT-* for mostly this reason).</div><div><br></div><div>So, qu=
estion:</div><div><br></div><div>Do we want to put a replay counter into HT=
2-*?</div><div><br></div><div>(I&#39;ll send a follow-up to <a href=3D"mail=
to:[email protected]">[email protected]</a> concerning the 0-RTT replay c=
ase specifically)</div><div><br></div><div>Dave.</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 22 Jun 2026 =
at 09:09, Florian Schmaus &lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On 12/05/2026 13.28, Florian Schmaus wrote:<br>
&gt; I&#39;ve uploaded draft-ietf-kitten-sasl-ht-01. The major changes sinc=
e the <br>
&gt; adoption by the Kitten WG are<br>
&gt; <br>
&gt; - the introduction of a response status byte to indicate success or<br=
>
&gt;=C2=A0 =C2=A0 failure responses<br>
&gt; - the capability to transmit authenticated key/value pairs in the<br>
&gt;=C2=A0 =C2=A0 exchanged messages (e.g., for XEP-0474 [1])<br>
&gt; <br>
&gt; <br>
&gt; SASL-HT is already deployed using an older and incompatible version of=
 <br>
&gt; the I-D in some parts of the XMPP ecosystem. Therefore, we probably ne=
ed <br>
&gt; to adjust the SASL Mechanism Name to avoid interoperability issues. Fo=
r <br>
&gt; example, from<br>
&gt; <br>
&gt; HT-SHA-512-ENDP<br>
&gt; <br>
&gt; to<br>
&gt; <br>
&gt; HT2-SHA-512-ENDP<br>
&gt; <br>
&gt; Please forgive my lack of creativity regarding the new name. Suggestio=
ns <br>
&gt; on a more creative naming schema that is in-line with the constraints =
of <br>
&gt; SASL Mechanism names are appreciated.<br>
&gt; <br>
&gt; And, of course, feedback in general is welcomed.<br>
I am going to ask the Kitten WG chair to initiate the next step for <br>
SASL-HT this week. Therefore, *now* would be a good time for feedback.<br>
<br>
FAST (XEP-0484) is currently using draft-schmaus-kitten-sasl-ht-09. The <br=
>
diff between this version and the lastest can be viewed via<br>
<br>
<a href=3D"https://author-tools.ietf.org/iddiff?url1=3Ddraft-schmaus-kitten=
-sasl-ht-09&amp;url2=3Ddraft-ietf-kitten-sasl-ht-02&amp;difftype=3D--html" =
rel=3D"noreferrer" target=3D"_blank">https://author-tools.ietf.org/iddiff?u=
rl1=3Ddraft-schmaus-kitten-sasl-ht-09&amp;url2=3Ddraft-ietf-kitten-sasl-ht-=
02&amp;difftype=3D--html</a><br>
<br>
The latest version of sasl-ht uses the HT2-* prefix for its SASl <br>
mechanism name, instead of the HT-* prefix used by version -09. This <br>
name adjustment was necessary because the wire protocol changed <br>
slightly. It is perfectly fine for XEP FAST to continue using -09. <br>
Support for HT2-*, and its advantages, like support for SASL downgrade <br>
protection, can be deployed alongside it a later time (and shouldn&#39;t <b=
r>
require any changes to XEP FAST).<br>
<br>
- Flow<br>
_______________________________________________<br>
Standards mailing list -- <a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]"=
 target=3D"_blank">[email protected]</a><br>
</blockquote></div>

--000000000000c21ad20654d3ad12--


--===============8315767032205781456==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS2l0dGVuIG1h
aWxpbmcgbGlzdCAtLSBraXR0ZW5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp
bCB0byBraXR0ZW4tbGVhdmVAaWV0Zi5vcmcK

--===============8315767032205781456==--