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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
