On Fri, Dec 14, 2018 at 10:11:38PM +0100, Martin Rex wrote:
> Nico Williams <n...@cryptonector.com> wrote:
> > On Wed, Dec 12, 2018 at 04:21:43PM -0600, David Benjamin wrote:
> >> We have one more update for you all on TLS 1.3 deployment issues. Over the
> >> course of deploying TLS 1.3 to Google servers, we found that JDK 11
> >> unfortunately implemented TLS 1.3 incorrectly. On resumption, it fails to
> >> send the SNI extension. This means that the first connection from a JDK 11
> >> client will work, but subsequent ones fail.
> >> https://bugs.openjdk.java.net/browse/JDK-8211806
> >
> > I'm told that OpenSSL accidentally takes the SNI from the initial
> > connection on resumption if there's no SNI in the resumption. This
> > seems like a very good workaround for the buggy JDK 11 TLS 1.3 client,
> > as it has no fingerprinting nor downgrade considerations.
>
> Just that this workaround is a no-go for any layered approach
> to SNI, where server-side processing of SNI is outside of the TLS stack.
I mean, that's already a problem for TLS 1.{0,1,2}, so I don't believe
that getting the SNI from the resumption ticket would be a problem on
this account.
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
