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 th
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
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 an
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 TL
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 B
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 interope
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
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
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
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 starti
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
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 n
FWIW, the situation Rich outlines has been true for all prior versions of
TLS as well; it's just that TLS 1.3 is so different that there's a lot more
advantage to doing TLS 1.3 only than (say) doing TLS 1.2 but not TLS 1.1.
This isn't the question asked, but for the most part, ClientHellos
generat
>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].
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 implement
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
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
17 matches
Mail list logo
