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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
