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