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

[Dennis Jackson <[e-mail]>]

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-certs/

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 “pause” extension. Rather than changing 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’t get 
> records with the pause extension or wait until the “done” message is 
> sent, etc), but this seems to me like an elegant solution.
>
>
>  during the presentation on Suppl
> During the Supplemental
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]