You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
proposal: crypto/tls: add support for exported authenticators #35758
Proposal to implement support for exported authenticators in crypto/tls as described in draft-ietf-tls-exported-authenticator-10. I'm happy to write a CL for this.
changed the title [-]crypto/tls: add support for exported authenticators[/-][+]proposal: crypto/tls: add support for exported authenticators[/+]on Nov 22, 2019
Hello @tatianab, this is not something we are likely to implement for the time being.
Go likes to wait until things mature and gain enough adoption to justify their complexity, and we basically never implement draft standards.
Before moving to a CL, we'd have to discuss what a safe and useful API looks like.
I haven't checked the draft in a long time, but I thought the point was to leverage the RFC 5705 exporters, which we already expose via ConnectionState.ExportKeyingMaterial, allowing this entire implementation to live outside the standard library.
crypto/tls stayed simple and robust over the years by implementing a tiny subset of the constellation of TLS features. When TLS 1.3 was new it was easy to maintain this tradition, but now that many additions are being proposed, we'll have to once again figure out what a useful minimal subset looks like.
The creation and validation of both authenticator requests and authenticators SHOULD be implemented inside the (D)TLS library even if it is possible to implement it at the application layer.
Does that change your opinion? Maybe an implementation could live outside of crypto/tls, say golang.org/x/crypto?
Activity
[-]crypto/tls: add support for exported authenticators[/-][+]proposal: crypto/tls: add support for exported authenticators[/+]FiloSottile commentedon Nov 22, 2019
Hello @tatianab, this is not something we are likely to implement for the time being.
Go likes to wait until things mature and gain enough adoption to justify their complexity, and we basically never implement draft standards.
Before moving to a CL, we'd have to discuss what a safe and useful API looks like.
I haven't checked the draft in a long time, but I thought the point was to leverage the RFC 5705 exporters, which we already expose via ConnectionState.ExportKeyingMaterial, allowing this entire implementation to live outside the standard library.
crypto/tls stayed simple and robust over the years by implementing a tiny subset of the constellation of TLS features. When TLS 1.3 was new it was easy to maintain this tradition, but now that many additions are being proposed, we'll have to once again figure out what a useful minimal subset looks like.
burgerdev commentedon Jan 21, 2026
Hey @FiloSottile,
the draft has been published as RFC 9261 in 2022. It also includes an API recommendation section, and specifically says:
Does that change your opinion? Maybe an implementation could live outside of
crypto/tls, say golang.org/x/crypto?Cheers, Markus
seankhliao commentedon Jan 21, 2026
Does this feature actually have any real world adoption to a significant degree where it's worth implementing in the standard library?