RFC9001/4.2: "Clients MUST NOT offer TLS versions older than 1.3. A badly configured TLS implementation could negotiate TLS 1.2 or another older version of TLS. An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated"
At least demultiplexing between HTTP TLS and QUIC TLS implementations should be an challenge due to encap differences. Sharing a single implementation maybe a bit more advanced if TLS/TCP should support 1.2. Cheers Toerless On Thu, Aug 05, 2021 at 04:58:54PM -0700, Christian Huitema wrote: > Also, it depends whether the application is HTTP or something else. QUIC > makes an explicit reference to version 1.3. AFAIK, several implementations > of QUIC use stacks that just implement 1.3, no attempts at backward > compatibility whatsoever. > > -- Christian Huitema > > On 8/5/2021 4:15 PM, Richard Barnes wrote: > > I’m not aware of any spec (at least in the IETF) that mandates support for > > prior versions. Are you? > > > > My point being that there is a pretty universal default assumption that no > > such requirement exists. No different for TLS, and thus no need to explain > > when that’s the case. > > > > —Richard > > > > On Thu, Aug 5, 2021 at 13:12 Toerless Eckert <t...@cs.fau.de> wrote: > > > > > Sure, i like playing TLS cluedo ;-) > > > > > > But for uneducated readers, i was thinking more about text that uplevels > > > to the operational > > > aspect of interoperability: > > > > > > All (curent) TLS versions can negotiate to lower versions, but > > > no version specification mandates actual support for such a lower > > > version. > > > > > > In result: to ensure interoperability with a peer of version 1.x, > > > it is not sufficient to support 1.y, where y > x, but an implementation > > > must explicitly also have support for 1.x. > > > > > > Btw: pretty sure that if i go back to my domain (IP Multicast for > > > example), > > > our text will likely not be any better, but TLS just has the biggest > > > interest > > > surface so it makes most sense to encourage authors to write the most > > > easily > > > read text. > > > > > > Cheers > > > Toerless > > > > > > > > > On Thu, Aug 05, 2021 at 03:57:07PM -0700, Eric Rescorla wrote: > > > > On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert <t...@cs.fau.de> wrote: > > > > > > > > > Another way to educate what you may consider to be "non-core" > > > readership, > > > > > is maybe some form of "TLS operational considerations". Your prior > > > answer > > > > > about that TLS server cluster consideration would also nicely fit into > > > > > something like that. Maybe something for opsec wg.. > > > > > > > > > This is in the next section: > > > > https://tools.ietf.org/rfcmarkup?doc=8446#appendix-D.3 > > > > > > > > -Ekr > > > > > > > > > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > (*) Not sure about the number. Could have been egyption or chinese > > > history > > > > > ;-) > > > > > > > > > > > > > > > On Thu, Aug 05, 2021 at 03:23:42PM -0700, Eric Rescorla wrote: > > > > > > On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert <t...@cs.fau.de> > > > wrote: > > > > > > > Thanks for the explanation. > > > > > > > > > > > > > > My main concern was just to understand clearly what requirements > > > > > > > have to be written into RFC when one wants to ensure that TLS 1.2 > > > needs > > > > > > > to be supported as the fallback in a particular solution. > > > > > > > > > > > > > > With TLS 1.3 not mandating support for TLS 1.2, in such cases > > > > > > > one > > > > > > > still needs to write MUST support TLS 1.2 > > > > > > > > > > > > That's correct. > > > > > > > > > > > > when one thought > > > > > > > a MUST TLS 1.3 might have sufficed (assuming it included TLS 1.2 > > > > > > > support). A bit more explanatory text in 8446 might have helped. > > > > > > > > > > > > > TBH, I think this is pretty clear in the document. We don't > > > > > > generally > > > > > expect > > > > > > that support for version X includes support for version X-1. > > > Moreover, > > > > > there > > > > > > is text in the document which doesn't make much sense if you > > > > > > couldn't > > > > > > just have a TLS 1.3 stack: > > > > > > > > > > > > This document defines TLS version 1.3. While TLS 1.3 is not > > > directly > > > > > > compatible with previous versions, all versions of TLS > > > > > > incorporate > > > a > > > > > > versioning mechanism which allows clients and servers to > > > > > > interoperably negotiate a common version if one is supported by > > > both > > > > > > peers. > > > > > > > > > > > > > > > > > > Or > > > > > > > > > > > > TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627 > > > > > > <https://tools.ietf.org/rfcmarkup?rfc=7627>] > > > > > > extension which digested large parts of the handshake transcript > > > into > > > > > > the master secret. Because TLS 1.3 always hashes in the > > > transcript > > > > > > up to the server Finished, implementations which support both > > > > > > TLS > > > 1.3 > > > > > > and earlier versions SHOULD indicate the use of the Extended > > > Master > > > > > > Secret extension in their APIs whenever TLS 1.3 is used. > > > > > > > > > > > > -Ekr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, the immediate status change of "obsoleted by 8446" may > > > > > > > make readers think that TLS 1.3 can take care of migration > > > > > > > from TLS 1.2 all by itself, when indeed it can not unless you > > > > > > > still also mandate implementing TLS 1.2. Of course we do not > > > > > > > have a better keyword vocabulary. Something like "Sunset by: > > > > > > > 8446". > > > > > > > > > > > > > > Cheers > > > > > > > Toerless > > > > > > > > > > > > > > On Thu, Aug 05, 2021 at 09:16:37PM +0000, Salz, Rich 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. > > > > > > > > > > > > > > > -- > > > > > > > --- > > > > > > > t...@cs.fau.de > > > > > > > > > > > > > > _______________________________________________ > > > > > > > TLS mailing list > > > > > > > TLS@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > > > > > -- > > > > > --- > > > > > t...@cs.fau.de > > > > > > > > -- > > > --- > > > t...@cs.fau.de > > > > > > _______________________________________________ > > > 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 -- --- t...@cs.fau.de _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
