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

[Kurt Roeckx]

On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote:
> 
> 
> > 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.

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