On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote: > > > > 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.
I think there might be some disagreement on how to go forward with having proper TLS in SMTP. I think Google might want to go with how it works for https, and so have certificates issued by a CA for hostname you try to connect to. I think you would like to use DANE instead. But I don't see DNSSEC or DANE getting wide adoption. I currently see 4 type of connections for my outgoing mail in my postfix log: - Verified TLS connection: self-signed DANE - Verified TLS connection: DANE but with a valid certificate - Untrusted TLS connection: People who have a valid certificate for the hostname I connect to - Anonymous TLS: Using an anoymous cipher, yet having a valid certificate This is of course a very limited amount, only for what I send, but I think TLS for SMTP is already in a much better state now. I think in the end we should just enforce proper certificates. It would be nice that all those that do have a proper certificate are actually marked as "Verified", there really is no reason to say they are Untrusted. It would also be nice that if the client sends an SNI and you have a certificate for it that it wouldn't select an anonymous cipher. But then postfix is probably the only one that does anonymous ciphers, and if it's not sending SNI this will not change much. But I don't agree to Google's use of SNI, saying that if it supports TLS 1.3 that it must be modern software that should send an SNI. The library (OpenSSL) will support it, but that doesn't mean that application will set it, or that upgrading OpenSSL will suddenly make the appliation set it. I also don't see a relation between not sending SNI and not checking the certificate, you can perfectly write code that does not send an SNI but does proplery validate the certificate. Kurt _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
