> On 22 Oct 2015, at 9:26 PM, Watson Ladd <watsonbl...@gmail.com> wrote: > > > On Oct 22, 2015 2:20 PM, "Salz, Rich" <rs...@akamai.com > <mailto:rs...@akamai.com>> wrote: > > > > > If we (okay, not "we", library implementors) require explicit application > > > opt- > > > in to TLS 1.3, the adoption rate is probably not going to be very good. > > > So, yes, > > > I think applications should start using TLS 1.3 without any changes. > > > > And what about 0RTT? Removed support for some crypto? Various other > > semantic changes? > > If you don't enable 0RTT support and ignore removed crypto, what breaks? Most > apps don't use renegotiation anyway? > > > > What you're really saying is "just like it always used to be, just better." > > > > And I want a pony. > > Most applications want a simple API that hides all the complexities of TLS. > If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't > cause problems for those apps which said "you take care of it”. > That is true only if your application’s client component and server component are using the same library. That is not guaranteed in a protocol. Specifically that is not the case with the web.
There are some version intolerant servers out there that will choke on seeing a TLS 1.3 ClientHello. If the client uses some library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that has TLS 1.3. All of the sudden your application is broken. On the web this means that some websites don’t work. Do you live with the application being sometimes broken? Do you make some downgrade dance? Hard question, and one that the application needs to answer. In any library it’s a major problem if an API call fails in the new version of the library where it would succeed in the old version. In a library implementing a protocol this could happen because of the network, because of middleboxes implementing their own version of “sanity” on the traffic, or because of peers that might have a different interpretation of the previous standard. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
