crypto/tls: make TLS 1.3 opt-out for Go 1.13

[rsc]

It seems clear from the history of filed issues that some users will experience minor disruptions when switching to TLS 1.3. For disruptive changes like that, we typically do one or more releases in which the new feature is opt-in, with a prominent announcement about when it will turn on by default. Then we do at least one release with the feature opt-out. (Past examples include HTTP/2, vendor directories, and modules.)

Especially given how central TLS is to so many Go users (any HTTPS client or server!), it seems like we should do that for TLS 1.3 too:

• Make TLS 1.3 available in Go 1.12 but opt-in (off by default).
• Make clear in the release notes and package docs how to turn on TLS 1.3.
• Make clear in the release notes that TLS 1.3 will turn on by default in Go 1.13.
• Make TLS 1.3 in Go 1.13 opt-out (on by default).

Following the HTTP/2 example my suggestion would be to use GODEBUG=tls13=1 for opt-in now, and GODEBUG=tls13=0 for opt-out later.

/cc @FiloSottile

[bradfitz]

Following the HTTP/2 example my suggestion would be to use GODEBUG=tls13=1 for opt-in now

That's fine as long as there's also a way to enable it in code. Via tls.Config somehow? (MaxVersion and MinVersion both seem wrong.) Or at least with os.Setenv at runtime, but that means crypto/tls would need to keep calling Getenv. New bool on tls.Config would be kinda unfortunate, but maybe?

[neild]

Should this apply to RSA-PSS as well?

[mvdan]

New bool on tls.Config would be kinda unfortunate, but maybe?

A perhaps less specific version could be Debug []string, e.g. tlsConfig.Debug = []string{"tls13=1"}. Then it can be reused for more on/off switches in future Go releases, and its behavior is consistent with GODEBUG.

[FiloSottile]

MaxVersion feels wrong semantically, and in practice it would lock applications to TLS 1.3 when TLS 1.4 ever comes out. I'm worried that tlsConfig.Debug would be a slippery slope, we get requests all the time to add all kinds of knobs which are inconsistent with the simplicity goal of crypto/tls, and that would provide an extra avenue for them.

How about GODEBUG=tls13=1, read once per tls.Config? It would allow os.Setenv in code, it would probably have acceptable performance, and still let applications test canaries without modifying code. It would probably have to be inherited via GetConfigForClient if one os.Getenv per connection is unacceptable.

[bradfitz]

MaxVersion = 0xFFFF would be my vote. Or some other unused constant to mean MaxBeta.

[bradfitz]

But users likely wouldn't be able to reach all such configs so the environment way probably best if Setenv works.

[gopherbot]

Change https://golang.org/cl/160998 mentions this issue: crypto/tls: disable RSA-PSS in TLS 1.2

[gopherbot]

Change https://golang.org/cl/160997 mentions this issue: crypto/tls: make TLS 1.3 opt-in

[FiloSottile]

CL 160997 just uses os.Getenv at every connection. On Unix it takes a brief lock but uses an internal view of the environment, so there is no syscall. On Windows it makes a syscall. We can test the performance before adding complexity the day before the RC.