[TLS] Re: Jonathan's "pause" extension

--===============2776453622573278529==
Content-Type: multipart/alternative; boundary="000000000000c1e6c706575adac8"

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

I think it should be handled at a higher layer where possible, but we don't
have good handles from higher layers to lower ones.
Most attempts to bind stuff to the TLS layer seem to fail the moment they
find that most libraries don't support it.

Having a "pause" extension at least gives the upper layers a knob to turn
that allows them to drive the upper layer protocols and know whether data
was transmitted before or after the upper layer protocol completed.

Regards,

Jonathan

On Thu, 23 Jul 2026 at 12:04, Dennis Jackson <ietf=3D
[email protected]> wrote:

> I feel that all of this 'supplemental authentication' *should* be
> handled at a higher layer, whether that's a HTTP middle layer or the
> application layer.
>
> My suggestion at the mic was that the TLS WG should provide some
> guidance on how to do this safely and effectively in a application
> agnostic manner. I don't think this needs any changes to TLS.
>
> For example, sketching how to combine TLS Exported Authenticators with
> additional certificates or PAKEs or other authentication flows and
> pointing to existing drafts in other WGs that already take this
> approach, e.g:
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-secondary-server-cert=
s/
>
> Best,
> Dennis
>
> On 23/07/2026 11:52, Salz, Rich wrote:
> > I wanted to bring to the list a suggestion Jonathan Hoyland might at
> > the mic line today.
> >
> > During the Supplemental Authentication discussion, several people
> > brought up the idea of using exporters and channel bindings (9261,
> > 9266). Yaroslav pointed out that it requires application changes to
> > use them.
> >
> > Jonathan suggested a =E2=80=9Cpause=E2=80=9D extension. Rather than cha=
nging the
> > handshake, this new extension would tell the peer that more data is
> > coming and do not accept/send application data until the pause is
> > lifted. He and I chatted after the session, and we realized this could
> > probably handle multi-exchange PAKE traffic as well. Anything that
> > would modify the handshake, or is normally post-handshake (cough,
> > authentication, cough) would also work. Probably need to nail down the
> > semantics such as when to lift the pause (E.g., when you don=E2=80=99t =
get
> > records with the pause extension or wait until the =E2=80=9Cdone=E2=80=
=9D message is
> > sent, etc), but this seems to me like an elegant solution.
> >
> >
> >  during the presentation on Suppl
> > During the Supplemental
> >
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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

<div dir=3D"ltr"><div>I think it should be handled at a higher layer where =
possible, but we don&#39;t have good handles from higher layers to lower on=
es.</div><div>Most attempts to bind stuff to the TLS layer seem to fail the=
 moment they find that most libraries don&#39;t support it.</div><div><br><=
/div><div>Having a &quot;pause&quot; extension at least gives the upper lay=
ers a knob to turn that allows them to drive the upper layer protocols=C2=
=A0and know whether data was transmitted before or after the upper layer pr=
otocol completed.</div><div><br></div><div>Regards,</div><div><br></div><di=
v>Jonathan</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, 23 Jul 2026 at 12:04, Dennis Jackson &lt;ietf=3D<a =
href=3D"mailto:[email protected]" target=3D"_blank">40denn=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">I feel that all of this &#39;supplemental authe=
ntication&#39; *should* be <br>
handled at a higher layer, whether that&#39;s a HTTP middle layer or the <b=
r>
application layer.<br>
<br>
My suggestion at the mic was that the TLS WG should provide some <br>
guidance on how to do this safely and effectively in a application <br>
agnostic manner. I don&#39;t think this needs any changes to TLS.<br>
<br>
For example, sketching how to combine TLS Exported Authenticators with <br>
additional certificates or PAKEs or other authentication flows and <br>
pointing to existing drafts in other WGs that already take this <br>
approach, e.g:<br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-httpbis-secondary-se=
rver-certs/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.=
org/doc/draft-ietf-httpbis-secondary-server-certs/</a><br>
<br>
Best,<br>
Dennis<br>
<br>
On 23/07/2026 11:52, Salz, Rich wrote:<br>
&gt; I wanted to bring to the list a suggestion Jonathan Hoyland might at <=
br>
&gt; the mic line today.<br>
&gt;<br>
&gt; During the Supplemental Authentication discussion, several people <br>
&gt; brought up the idea of using exporters and channel bindings (9261, <br=
>
&gt; 9266). Yaroslav pointed out that it requires application changes to <b=
r>
&gt; use them.<br>
&gt;<br>
&gt; Jonathan suggested a =E2=80=9Cpause=E2=80=9D extension. Rather than ch=
anging the <br>
&gt; handshake, this new extension would tell the peer that more data is <b=
r>
&gt; coming and do not accept/send application data until the pause is <br>
&gt; lifted. He and I chatted after the session, and we realized this could=
 <br>
&gt; probably handle multi-exchange PAKE traffic as well. Anything that <br=
>
&gt; would modify the handshake, or is normally post-handshake (cough, <br>
&gt; authentication, cough) would also work. Probably need to nail down the=
 <br>
&gt; semantics such as when to lift the pause (E.g., when you don=E2=80=99t=
 get <br>
&gt; records with the pause extension or wait until the =E2=80=9Cdone=E2=80=
=9D message is <br>
&gt; sent, etc), but this seems to me like an elegant solution.<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0during the presentation on Suppl<br>
&gt; During the Supplemental<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a><br>
&gt; To unsubscribe send an email to <a href=3D"mailto:[email protected]" =
target=3D"_blank">[email protected]</a><br>
<br>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
</blockquote></div>

--000000000000c1e6c706575adac8--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK

--===============2776453622573278529==--