Go: crypto/tls: add support for TLS 1.3

[mikioh]

See https://tools.ietf.org/html/draft-ietf-tls-tls13.

Coexistence of IPv4 and IPv6 harms the net package.
Coexistence of HTTP/1.x and HTTP/2 will harm the net/http package.
For now looks coexistence of TLS 1.2 and 1.3 won't harm the crypto/tls package.
How about a variety of compositions on HTTP over TLS over IP?

[bradfitz]

Coexistence of IPv4 and IPv6 harms the net package.

Huh?

Coexistence of HTTP/1.x and HTTP/2 will harm the net/http package.

Huh?

This whole bug report seems to start on unfounded premises, or at least isn't clear.

[rsc]

The draft is still being updated. We can talk about having TLS 1.3 once it's actually an RFC.

[I have no idea what the text in the issue report body is supposed to mean, but the issue title is at least clear.]

[joshuarubin]

maybe it's time to consider this again?

[minux]

TLS 1.3 is still not approved, so I think we should delay this
a bit further.

[FiloSottile]

https://go-review.googlesource.com/#/c/33115/ opened a branch for TLS 1.3 development.

[gopherbot]

CL https://golang.org/cl/33164 mentions this issue.

[gopherbot]

CL https://golang.org/cl/33416 mentions this issue.

[gopherbot]

CL https://golang.org/cl/33419 mentions this issue.

[mholt]

I see this is still "Unplanned" -- any possibility of getting this on track for Go 1.9? (Or is the final draft still too far out. I can never figure out where to find the status of these things.)

[bradfitz]

@FiloSottile is working on this. Status?

[FiloSottile]

The server codebase we are using is pretty battle tested and complete now, so the commits starting crypto/tls in https://github.com/cloudflare/tls-tris will make their way into CLs after cleanup. Some already did.

If @agl has the review bandwidth, I can probably power through the client implementation in March. (Or maybe we can consider shipping server first?)

BTW, @bradfitz it would be useful if I could submit for review on Gerrit commits I don't Author. There are a couple in there made by other people that agreed to have them submitted and signed the CLA.

(Feel free to assign me this issue.)

[bradfitz]

@FiloSottile, email me the list of author email addresses you wish to push forged commits to Gerrit with. I'll then check their CLAs and verify they're cool with you spoofing them. (Maybe cc them on your email to me and have them confirm?)

[gopherbot]

CL https://golang.org/cl/48455 mentions this issue.

[gopherbot]

CL https://golang.org/cl/48454 mentions this issue.

[gopherbot]

Change https://golang.org/cl/79738 mentions this issue: [RFC] crypto/tls: advertise PSS support, add tests

[gopherbot]

Change https://golang.org/cl/79736 mentions this issue: crypto/tls: add RSASSA-PSS support for handshake messages

[wongsyrone]

IESG approved TLS 1.3: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/history/

[dougnd]

RFC8446 is published!

[gopherbot]

Change https://golang.org/cl/144578 mentions this issue: crypto/tls: implement TLS 1.3 extensions for ClientHello and ServerHello

[gopherbot]

Change https://golang.org/cl/145297 mentions this issue: crypto/tls: implement TLS 1.3 record layer and cipher suites

[gopherbot]

Change https://golang.org/cl/145298 mentions this issue: crypto/tls: implement TLS 1.3 cryptographic computations

[gopherbot]

Change https://golang.org/cl/145477 mentions this issue: crypto/tls: implement TLS 1.3 version-specific messages

[gopherbot]

Change https://golang.org/cl/146217 mentions this issue: crypto/tls: implement TLS 1.3 version negotiation

[gopherbot]

Change https://golang.org/cl/146258 mentions this issue: crypto/tls: advertise and accept rsa_pss_rsae signature algorithms

[gopherbot]

Change https://golang.org/cl/146559 mentions this issue: crypto/tls: implement TLS 1.3 client handshake (base)

[gopherbot]

Change https://golang.org/cl/147017 mentions this issue: crypto/tls: implement TLS 1.3 server handshake (base)

[gopherbot]

Change https://golang.org/cl/147420 mentions this issue: crypto/tls: implement TLS 1.3 PSK authentication (client side)

[gopherbot]

Change https://golang.org/cl/147417 mentions this issue: crypto/tls: implement TLS 1.3 KeyLogWriter support

[gopherbot]

Change https://golang.org/cl/147418 mentions this issue: crypto/tls: implement TLS 1.3 KeyUpdate messages

[gopherbot]

Change https://golang.org/cl/147419 mentions this issue: crypto/tls: implement TLS 1.3 middlebox compatibility mode

[gopherbot]

Change https://golang.org/cl/147445 mentions this issue: crypto/tls: implement TLS 1.3 PSK authentication (server side)

[gopherbot]

Change https://golang.org/cl/147599 mentions this issue: crypto/tls: implement TLS 1.3 client authentication

[gopherbot]

Change https://golang.org/cl/147617 mentions this issue: crypto/tls: implement TLS 1.3 downgrade protection

[gopherbot]

Change https://golang.org/cl/147638 mentions this issue: crypto/tls: enable TLS 1.3 and update tests

[timcooijmans]

@FiloSottile With this last commit, is TLS 1.3 support ready for testing?

[FiloSottile]

Once it gets merged (and this issue closed), you are very welcome to test TLS 1.3 by using Go master. Please file feedback and bugs as new GitHub issues and tag me. Note that the codebase will undergo much more testing before we are ok with shipping it in 1.12, so you shouldn't rely on its security the same way you shouldn't rely on master to be bug free.

[tie]

@FiloSottile, thanks for your awesome work!

I've looked through the commits and didn't find anything related to the encrypted SNI. Are there any plans on implementing the spec? Mozilla and Cloudflare have already implemented ESNI (though it's currently not enabled by default in Firefox).

[FiloSottile]

We generally wait for the browsers to experiment with new TLS features before implementing them, and anyway we are extremely unlikely to implement an Internet-Draft, so there are no plans for encrypted SNI.

Also, crypto/tls has a high benefit/complexity bar, so we will want to wait until encrypted SNI is widely deployed before implementing it.

[lvht]

hi @FiloSottile , does the current implement support the 0-RRT?

[bradfitz]

@lvht, no, it does not. Not for Go 1.12.

[lvht]

@bradfitz is there a roadmap to implement the 0-RRT?

[bradfitz]

I can't find the email now, but I recall @FiloSottile saying somewhere it could come later once we have more time to think about the API for it. (For security reasons, it can't be automatic, but perhaps net/http's Transport could use it for idempotent requests on new connections...)

[Henrocker]

@FiloSottile Is there any update on the 0-rtt earlydata progress?

[FiloSottile]

@Henrocker It's not currently on the roadmap. It will also depend on how the ecosystem develops.

[kf6nux]

@Henrocker , did you mean to post that question to github.com/caddyserver/caddy ? They maintain their issues in their own repo.