Re: [TLS] RFC8446 backward compatibility question

[Eric Rescorla <[e-mail]>]

On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert <[e-mail]> 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 <[e-mail]> 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.
> > > >
> > > >
> > >
> > > --
> > > ---
> > > [e-mail]
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
>
> --
> ---
> [e-mail]
>