On Wed, Apr 09, 2025 at 07:51:59PM -0700, Eric Rescorla wrote:
> Perhaps not, but that's not what I am saying. Rather, the point I am
> making is that your proposed text limiting this to *browsers* is far too narrow and the
> original text that says TLS 1.3 is widely deployed is in fact correct. "Widely" is
> not the same as "universally".
Absence of any qualification just makes it easy to read "universally".
How about "widely used in browser applications and widely available in curent IT operating systems"
?
> > The reason is again the really long time lines and cost of upgrading OS's. For another fun
> > example, i think some tram systems used windows CE 3.11 until after 2015 and since
> > then have adopted something that sounded like Windows CE XP level.
>
> I'm aware that many embedded systems run very old software. But the relevant
> question is whether there are systems which (1) cannot deploy TLS 1.3 and
> (2) are going to deploy entirely new protocols.
"cannot" and "entirely new" of course being underspecified.
To me, "cannot" includes cost or operationally prohibitive, but also
security-wise not-valuable or even counter-productive. If you disagree on
this, then that's ar least a good reason to ask for better qualification
of those two terms in the draft.
For example, there are enough IoT/embedded systems running for 10++ years,
where there are software upgrades/extensions, and those extensions could be "entirely new" protocols.
Assume some embedded device in some manufacturing plant (robots, assembly line systems, ...)
or mobile/transportation device (plane, train, automobile, submarine, drone, spaceship, satellite,
...), or oil exploration rig or the like. Let's say constraint is not an issue. But
the devices software alrady runs some/several protocols on top of TLS and
the SDK used supports only TLS 1.2, but not 1.3.
Now you want to add some "entirely" new lifecycle-automation-enhancement protocols. Stuff we
(IETF) actually produce - firmware management, credential management, bootstrap, configuration,
device-managment, security-management. Aka: app/ops/sec protocols relevant to us (IETF).
Option 1: The developer thinks about upgrading the system library with a 1.3 capable
version (if there is one for the OS used). Now he can pretty much re-qualify the whole
deployment system, not only the device, because existing protocol connections may
randomnly start to use TLS 1.3 but fail on code-path issues or interop issues. Could
bring down a manufacturing plant or plane without significant re-qualification.
Option 2: The developer tries to use the system libraries/SDK new version supporting TLS 1.3
only for the new add-on protocol/component. Good luck with that. Unless you've got
a containerized environment available, you'll fail on conflicts between different
library versions, for example just because of config file conflicts.
Option 3: The developer has to become a TLS library market expert, because now he has to find a new,
secondary library supporting TLS 1.3, which does not conflict with the existing TLS 1.2
system library or its config-files. Seems to be very cost prohibitive to do such
investigations / additional choices / working with two separate SDK - and maintaining two
system level configs.
Now even if e.g.: option 3 would be possible to do: You then look at the overall
system security, where everything except that new protocol is still using TLS 1.2 - and
wonder if the effort was worth it to the security of the system. Most likely, if you
do discover that your existing systems build-in (TLS 1.2) security has issues, what
you do is to build additional security perimeters. And yes, the IETF tries to ignore
firewalls, but now we even build "entirely new" protocols for them, such as MUD to
do exactly that "additional layers of security in the network system", because in reality,
in most non-Internet deployments, crypto agility can just not be as fast as we would like it
to be.
Also: crypto agility would be better if/when we can have SDK where each app
can be bound to a separate version of the same SDK, and system level config-management for the SDK
per-app parameters also support this. I think that's going to be a front and center problem
for the introduction of TLS/QUIC+PQ, because there we will run again into the same issues
as now for 1.2 vs. 1.3. Alas, this level of software manageability requirements has so
far not been within the scope of IETF thinking. And some oS already do have multi-version
support in higher-layer SDK, such as .NET in windows, but from all i understand, TLS is
still part of the lower-layer windows SDK, thus only one-version for all apps.
So yes, i think it is a front-and-center problem for many possible "totally new" protocols in the
IETF if we define our requirements against the realities of system and software managability,
in enviroments which are not as agile as "phone/notebook/pc + browser", or if we continue
to collapse our scope of applicability to that space.
Cheers
Toerless
Btw: I would appreciate if you would not only question what i say if you disagree and
be silent if you have no come back, but provide positive ACK when you do not disagree with
statements. Otherwise it is very hard for readers to understand likely conclusions/agreements.
>
> > As Alan observes, we are talking about levies on new protocols, not
> > > existing protocols. These should be deployed with TLS 1.3 for the reasons
> > > indicated in this draft.
> >
> > That restatement does not address the concerns i already raised.
> >
>
> I'm not really persuaded of the force of those concerns.
>
> -Ekr
--
---
tte@xxxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
