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

[Viktor Dukhovni]

> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> There is no "the name that is being verified".  The Postfix SMTP client accepts multiple (configurable as a set) names for the peer endpoint.  This may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or some fixed hardcoded-name, or a mixture of these...

Furthermore, with SMTP servers we can't be sure whether the peer even tolerates SNI, it may decide that it has no certificate exactly matching the client's guess, and hang up, even though the client would be happy with the default certificate.

I'm reluctant to start sending SNI in configurations that work fine without SNI, and could well break when it is introduced.  So if you're at all in touch with the Gmail folks, please work with them to undo the ratchet in question, at least SMTP MUST NOT suddenly stop yielding the expected default certificate for lack of SNI.

And just recompiling against OpenSSL 1.1.1 headers should not suddenly change behaviour.
On the server side there needs to be some recognition of application context, with HTTP servers requiring SNI (where appropriate), but SMTP and other similar applications not doing so.

I'd like to use TLS 1.3 in SMTP, even by default on a recompile or run-time relink with no code changes to explicitly enable TLS 1.3.  But if servers are going to put up unnecessary roadblocks, TLS 1.3 is not going to get much traction.

Please reconsider this particular ratchet (for at least SMTP).  It *is* counter-productive.

Not sure what OpenSSL should do at this point... :-(

-- 
	Viktor.