Since Go 1.12 contains a different implementation of TLS 1.3, the divergence between upstream and tris will only grow. This means that it is harder to pick up features and bugfixes from upstream, and to prepare changes for upstreaming.
The plan is to rebase/redo changes on top of upstream and adapt its TLS 1.3 implementation. We do not necessarily have to track point releases (e.g. Go 1.14) and could import pending changes that have not been released in a major version yet.
The purpose of tris would remain the same: enable early experimentation which is not possible with a stable API promise from upstream. This includes PQ key exchanges, ESNI, DC, etc.
Since Go 1.12 contains a different implementation of TLS 1.3, the divergence between upstream and tris will only grow. This means that it is harder to pick up features and bugfixes from upstream, and to prepare changes for upstreaming.
Tris used to be rebased (https://github.com/cloudflare/tls-tris/wiki/Rebase), but a trivial rebase is not possible at the moment due to the above. A list of upstream changes for Go 1.10, 1.11 and 1.12 can be found at https://github.com/cloudflare/tls-tris/issues/166#issuecomment-481641152
Changes in Go 1.13 and pending changes for Go 1.14:
Other unmerged upstream changes in development can be tracked at https://go-review.googlesource.com/q/status:open+tls+status:open
The plan is to rebase/redo changes on top of upstream and adapt its TLS 1.3 implementation. We do not necessarily have to track point releases (e.g. Go 1.14) and could import pending changes that have not been released in a major version yet.
The purpose of tris would remain the same: enable early experimentation which is not possible with a stable API promise from upstream. This includes PQ key exchanges, ESNI, DC, etc.