> On Apr 18, 2018, at 6:23 PM, David Benjamin <david...@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.
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
