Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert <[e-mail]>]

On Thu, Aug 05, 2021 at 01:15:30PM -1000, Richard Barnes wrote:
> I’m not aware of any spec (at least in the IETF) that mandates support for
> prior versions.  Are you?

Try to read from RFC3376 (IGMPv3) whether it is possible to build an implementation
compliant with the spec that is not interoperable with IGMPv1, IGMPv2.

I am pretty sure there is no IGMPV3 implementation in the industry
that is not compatible with IVMPv1, IGMPv3, so the question and IMHO 
lack of explicitness in the text never came up as an issue. But in this
thread i learned that this is the case for TLS 1.3 implementations.

> My point being that there is a pretty universal default assumption that no
> such requirement exists.

You underspecified requirements: Requirements against specifications for N+1 protocols
or requirements for adopters to understand interoperability implications based
on what protocol versions a product declares to support ?

Of course there are no specifications by the IETF that N+1 protocols MUST be
backward compatible with N. But i think there is a lot of benefit of explaining
to readers this upfront instead of expecting some (where is it from) common knowledge.

> No different for TLS, and thus no need to explain when that’s the case.

Sure. Just remove TLS 1.2 support from all your products that support TLS 1.3,
and see how many customers will still buy the product and only fail in
deployment interoperabiltiy, because they didn't see the problem during RPF
phase, thinking TLS 1.3 obviously is backward compatible. 
[  And please let me know upfront when you do, so i can short some stock and finally
   make a killling off of it ;-)) ]

Aka: When the mayority of protocol implementations that users have experience
with have included backward compatibility with older version then it is really prudent to
highlight the interop considerations into the specs  explicitly, and not just as
a game of cluedo or "common law" when you see that you may now go into
a phase of products where this is maybe no longer the case.

Cheers
    Toerless

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

-- 
---
[e-mail]