Skip to content

proposal: crypto/tls: add support for exported authenticators #35758

Open

Description

@tatianab

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.

cc @grittygrease @wbl

Activity

  1. changed the title [-]crypto/tls: add support for exported authenticators[/-] [+]proposal: crypto/tls: add support for exported authenticators[/+] on Nov 22, 2019
  2. added this to the Proposal milestone on Nov 22, 2019
  3. added
    Proposal-CryptoProposal related to crypto packages or other security issues
    and removed on Nov 22, 2019
  4. FiloSottile commented on Nov 22, 2019

    @FiloSottile
    Contributor

    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.

  5. added this to Go Security and removed this from Go Securityon Sep 8, 2022
  6. burgerdev commented on Jan 21, 2026

    @burgerdev

    Hey @FiloSottile,

    the draft has been published as RFC 9261 in 2022. It also includes an API recommendation section, and specifically says:

    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?

    Cheers, Markus

  7. seankhliao commented on Jan 21, 2026

    @seankhliao
    Member

    Does this feature actually have any real world adoption to a significant degree where it's worth implementing in the standard library?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions