FWIW, the situation Rich outlines has been true for all prior versions of TLS as well; it's just that TLS 1.3 is so different that there's a lot more advantage to doing TLS 1.3 only than (say) doing TLS 1.2 but not TLS 1.1.
This isn't the question asked, but for the most part, ClientHellos generated by stacks which support both TLS 1.3 and TLS 1.2 will be compatible with unmodified TLS 1.2 servers, thus allowing for clients to upgrade even when servers have not. The exception is that if a TLS 1.3 client is attempting 0-RTT (which it can only do if it has already successfully connected with TLS 1.3 to the server), then this is not compatible with TLS 1.2. Thus, if you have multiple servers associated with a given address you need to ensure that they all speak TLS 1.3 prior to advertising 0-RTT. It is safe, however to upgrade only some of them to TLS 1.3 as long as you do not advertise 0-RTT because the ClientHello will still be TLS 1.2 compatible. -Ekr On Thu, Aug 5, 2021 at 2:17 PM Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> wrote: > > I am trying to figure out if every implementation compliant with > RFC8446 is also necessarily interoperable with an RFC5246 peer, or if > this > is just a likely common, but still completely optional implementation > choice. > > It is possible to have a single stack that implements TLS.[123]. OpenSSL, > among many others does this. Some have implemented ONLY TLS 1.3; that code > tends to be cleaner (in a nerd esthetic sense) than code that implements > multiple protocols. Some servers even "hand off" pre-1.3 protocols to > separate implementations (libraries); FB and Amazon used to do that. > > The wire protocol for TLS 1.3 uses some deliberately-reserved extension > fields so that a server which doesn't do 1.3 can fail cleanly, and a server > that DOES will work. And also the other way, a 1.3 client can work fine > with both a 1.3 server and a 1.[12] server. > > It's easy to rationale 1.3-only for clients. It is harder to rationalize > 1.3-only for servers if you are intending those servers to be generally > accessible on the public Internet. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
