<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 18, 2018 at 7:27 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Apr 18, 2018, at 6:23 PM, David Benjamin <<a href="mailto:davidben@google.com" target="_blank">davidben@google.com</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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.  <br></blockquote><div><br></div><div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>Separately, on the particular SNI incarnation of this general issue:</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since OpenSSL won't know whether it is doing SMTP or HTTP, or whatever, it means<br>
that OpenSSL will need to disable TLS 1.3 in the absence of SNI across the board.<br>
<br>
Consequently, opportunistic SMTP clients (or those using mandatory TLS, but without<br>
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.<br></blockquote><div><br></div><div><div>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.</div><div><br></div><div>(The DANE case is not very relevant to how Google's servers currently behave because they do not use DANE.)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Alternatively, replace sending SNI with supporting RSA-PSS, and the motivation for requiring RSA-PSS in TLS 1.3 drops out.</div><div><br></div><div>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.</div><div><br></div><div>Hopefully that helps clarify the reasoning a bit here.</div></div></div>