[openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

[Viktor Dukhovni]

> On Apr 18, 2018, at 6:23 PM, David Benjamin <davidben at google.com> wrote:
> 
> Rather than break existing clients, with TLS 1.3 we are trying a more incremental approach: if a client is new enough to support TLS 1.3 then either it should be sending SNI, or we'll give it a dummy certificate.

So it sure seems like we can't introduce a transparent transition to TLS 1.3 without taking care to disable TLS 1.3 when SNI is not provided.  

Since OpenSSL won't know whether it is doing SMTP or HTTP, or whatever, it means
that OpenSSL will need to disable TLS 1.3 in the absence of SNI across the board.

Consequently, opportunistic SMTP clients (or those using mandatory TLS, but without
DANE where the SNI value is still a guessing game we did not play) won't get TLS 1.3, until they start to make up some sort of SNI name.

It seems to me that all the incentive that clients need to send SNI is not getting the right certificate if they don't, but deliberately withholding the default certificate and sending self-signed invalid is hugely counter-productive.

IMHO, such strategies just delay TLS 1.3 deployment.  If there's a sensible default cert, please don't punish the client and fail to send it.  This sort of thing does not lead to the desired outcome, it just forces work-arounds (such as not doing TLS 1.3).

-- 
	Viktor.