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

[David Benjamin]

On Wed, Apr 18, 2018 at 7:27 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
>
> > On Apr 18, 2018, at 6:23 PM, David Benjamin <davidben at 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.
>

I think the TLS 1.3 transition concerns are orthogonal to SNI and this
particular server behavior. At the end of the day, TLS 1.3 does not behave
the same as TLS 1.2 and intentionally has many ratcheting changes.

Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1
does not work in TLS 1.3, only PSS. Consider a caller which calls
SSL_renegotiate. I see that function just fails in TLS 1.3 in OpenSSL right
now. A client which expects the session to be available immediately after
the handshake will also break. Or someone who listens to the message
callback. Or someone who only installed CBC-mode ciphers in initialization.
Or just someone who calls SSL_version and checks that it is TLS1_2_VERSION.

Ultimately, improving TLS in TLS 1.3 means that, although it is a drop-in
upgrade for most scenarios, TLS 1.3 has different deployment considerations
at implementation-dependent corner cases.

OpenSSL is ABI-stable and expects to be updated underneath the calling
application. This means most behavior changes—certainly major protocol
revisions!—are risky. At the same time, it is desirable to have TLS 1.3
enabled for most consumers. This is the usual dilemma: stability for the
uncommon case impedes progress for the common case.

I might suggest conditioning it on the compile-time version of OpenSSL
headers. This is a common transition strategy for systems working through
ABI constraints. (In some systems, this is implemented as some target SDK
version.)

Separately, on the particular SNI incarnation of this general issue:


> 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.
>

I'm not sure I follow this. Why is the SNI value a guessing game? The
client that does not verify the certificate does not care what certificate
it gets. (This is why we still send something, rather than close the
connection.) The client that does verify a certificate, whether or not
failures are fatal, does not need to guess: use the name that is being
verified.

(The DANE case is not very relevant to how Google's servers currently
behave because they do not use DANE.)


> 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).
>

Indeed, the goal is so that clients do not get the right certificate if
they do not send SNI. Sending the default certificate does not achieve
this. The current ecosystem does not reliably send SNI. Without incentives,
it will remain that way. One must arrange for new entrants to behave, so
that someday one can rely on the ecosystem to behave overall. TLS 1.3 is
the ratchet to implement that.

Alternatively, replace sending SNI with supporting RSA-PSS, and the
motivation for requiring RSA-PSS in TLS 1.3 drops out.

Or consider OpenSSL’s default TLS version. Existing OpenSSL consumers are
not reliably TLS-1.3-compatible, so the default cannot be switched. But if
one does not switch the default, new consumers will not enable TLS 1.3, and
will remain TLS-1.3-incompatible. Thus the proposal to use the compile-time
version as ratchet.

Hopefully that helps clarify the reasoning a bit here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180419/53677f06/attachment-0001.html>