crypto/tls: add VersionName function to return a string version of the TLS Version

[skgsergio]

I propose to add a func VersionName(version uint16) string method that returns a string representation (TLSv1.0, TLSv1.1, ...) given a version id.

Currently crypto/tls provides similar functionality for the cipher suites but not for the version. I've seen myself and others implementing this in our codes to print it in logs and other places, but this is far from ideal as, for example, if a new protocol is added in the future, that code would be outdated.

I couldn't find any related issue or ongoing work so I'll be opening a PR.

[gopherbot]

Change https://golang.org/cl/321733 mentions this issue: crypto/tls: add crypto/tls.VersionName function

[dmitshur]

CC @FiloSottile, @katiehockman, @rolandshoemaker via owners.

[networkimprov]

cc @ianlancetaylor re likely proposal

[rsc]

ping @FiloSottile @rolandshoemaker @katiehockman

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

ping @FiloSottile @rolandshoemaker @katiehockman

[rolandshoemaker]

Generally seems reasonable.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[mvdan]

Was a String method considered? I imagine that the problem might be that making the constants use a named type rather than be left as untyped integers might break some users, but I can't help but feel like a top-level "to string" function feels out of place :)

[FiloSottile]

Is there a way to convert the constants to a named type within the Go 1 Compatibility Promise?

[mt-inside]

If there could be a named type someone, a String() method (and thereby satisfying fmt.Stringer) would play very nicely with go 1.18 generics...

[ianlancetaylor]

CC @golang/security

Do we want to try to get this into 1.19? Otherwise, what should the milestone be?

@FiloSottile Converting an untyped constant to a named type technically violates the Go 1 compatibility guarantee.

[rolandshoemaker]

Seems unlikely to happen for 1.19, moving to 1.20 seems fine.

[ehaughee]

I am writing my own stop-gap for this functionality but would like to swap that impl for this proposal once available. Is there an inclination/decision towards the expected string value/pattern for these names? For instance, will it match the CipherSuiteName pattern of being a direct map of const name to string value (e.g. tls.VersionSSL30 becomes "VersionSSL30"?

[skgsergio]

When I did the PR I used the names that are most common everywhere for representing each version instead of using the constant name.

[gopherbot]

Change https://go.dev/cl/497377 mentions this issue: crypto/tls: add VersionName