> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni <[email protected]>
> 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.
_______________________________________________
openssl-project mailing list
[email protected]
https://mta.openssl.org/mailman/listinfo/openssl-project
