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
--
---
t...@cs.fau.de
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
