Re: [TLS] RFC8446 backward compatibility question

[Valery Smyslov]

Hi Toerless,

> Eric,
> 
> What you call "pretty clear" is IMHO quite indirect. And yes, i tried
> to find evidence and stumbled exactly on that second example and then was
> not 100% sure...
> 
> My comments where just trying to provide friendly feedback from
> a TLS uneducated reader. Remember that TLS is just recently starting
> to proliferate into markets like IoT, so an expectation of knowledge about
> 6000 years of TLS history may not to be expected for broadest readership
> of the RFCs (*).
> 
> 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..

UTA WG is concerned with using TLS in applications.
In particular, RFC 7525 (currently being updated, see 
draft-ietf-uta-rfc7525bis) 
gives some operational recommendations on supporting different versions of TLS.

Regards,
Valery.

> 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  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
> > ]
> >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 +, 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

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

Well, i can only repeat myself: Practically obsoleting TLS 1.2 will be less
painfull when everybody who is designing, planning and deploying
solutions is well aware that TLS 1.2 interop is not implied by TLS 1.3,
even when the past and maybe even still dominant experience is that
implementations of TLs used for HTTP and supporting TLS 1.3 also
did/do support TLS 1.2.

Cheers
Toerless

history of TLS was very much that TLS 1.x implementations
tended to be back backward compatible wit
IMHO: As long as these different  Given how we want to obsolete TLS 1.2 it is a 
good thing, whenever
it is communicated such that there are no later unexpected interop
issues

On Thu, Aug 05, 2021 at 05:30:03PM -0700, Christian Huitema wrote:
> QUIC specifications are definitely not ambiguous. My point is that QUIC
> provides incentives to develop TLS stacks that only support 1.3 and later
> releases. Someone is going to use these stacks in other applications.
> Special purpose web servers would be one such application, say supporting H3
> and providing a fallback to H2. So I certainly believe that we will find
> deployments of TLS over TCP that are only supporting TLS 1.3. Whether that's
> a good idea is something that the market will decide...
> 
> -- Christian Huitema
> 
> On 8/5/2021 5:14 PM, Toerless Eckert wrote:
> > 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  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  
> > > > > > 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 
> > > > > wrote:
> > > > > > > > > Thanks for the explanation.
> > > > > > > > > 
> > > > > > > > > My main concern 

Re: [TLS] RFC8446 backward compatibility question

[Christian Huitema]

QUIC specifications are definitely not ambiguous. My point is that QUIC 
provides incentives to develop TLS stacks that only support 1.3 and 
later releases. Someone is going to use these stacks in other 
applications. Special purpose web servers would be one such application, 
say supporting H3 and providing a fallback to H2. So I certainly believe 
that we will find deployments of TLS over TCP that are only supporting 
TLS 1.3. Whether that's a good idea is something that the market will 
decide...


-- Christian Huitema

On 8/5/2021 5:14 PM, Toerless Eckert wrote:

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  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  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 

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
]
 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 

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

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  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  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 
> > > 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
> > > > > > ]
> > > > > > 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 

Re: [TLS] RFC8446 backward compatibility question

[Christian Huitema]

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  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  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 

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
]
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 +, 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 

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

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  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  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 
> > 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
> > > > 

Re: [TLS] RFC8446 backward compatibility question

[Richard Barnes]

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  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  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 
> 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
> > > > ]
> > > >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 +, 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 

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

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  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  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
> > > ]
> > >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 +, 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 

Re: [TLS] RFC8446 backward compatibility question

[Eric Rescorla]

On Thu, Aug 5, 2021 at 3:52 PM Toerless Eckert  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  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
> > ]
> >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 +, 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

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

Eric,

What you call "pretty clear" is IMHO quite indirect. And yes, i tried
to find evidence and stumbled exactly on that second example and then was
not 100% sure...

My comments where just trying to provide friendly feedback from
a TLS uneducated reader. Remember that TLS is just recently starting
to proliferate into markets like IoT, so an expectation of knowledge about
6000 years of TLS history may not to be expected for broadest readership
of the RFCs (*). 

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..

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  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
> ]
>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 +, 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

Re: [TLS] RFC8446 backward compatibility question

[Eric Rescorla]

On Thu, Aug 5, 2021 at 2:37 PM Toerless Eckert  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
]
   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 +, 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8446 backward compatibility question

[Toerless Eckert]

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 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.

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 +, 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

Re: [TLS] RFC8446 backward compatibility question

[Salz, Rich]

>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

Re: [TLS] RFC8446 backward compatibility question

[Richard Barnes]

For example, the mint TLS 1.3 library only supports 1.3.

https://github.com/bifurcation/mint

On Thu, Aug 5, 2021 at 10:46 AM Nick Harper  wrote:

> Yes, backward compatibility is optional.
>
> On Thu, Aug 5, 2021 at 1:44 PM Toerless Eckert  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.
>>
>> I could not find any explicit statement that backward compatibility
>> with RFC5246 is mandatory (but i just was doing browsing/keyword search
>> over RFC8446). COnditional text such as:
>>
>> "implementations which support both TLS 1.3 and earlier versions SHOULD"
>>
>> make me think that TLS 1.2 backward compatibility is just optional.
>>
>> Thanks
>> Toerless
>>
>> ___
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8446 backward compatibility question

[Nick Harper]

Yes, backward compatibility is optional.

On Thu, Aug 5, 2021 at 1:44 PM Toerless Eckert  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.
>
> I could not find any explicit statement that backward compatibility
> with RFC5246 is mandatory (but i just was doing browsing/keyword search
> over RFC8446). COnditional text such as:
>
> "implementations which support both TLS 1.3 and earlier versions SHOULD"
>
> make me think that TLS 1.2 backward compatibility is just optional.
>
> Thanks
> Toerless
>
> ___
> 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