> 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".
That would be a misreading. > How about "widely used in browser applications and widely available in > curent IT operating systems" I continue to believe the text is fine as-is. > > > 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. Well, at least as far as "new" goes, this is why we have people on the IESG who can exercise judgement. > 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. FWIW, it's not at all uncommon to statically link the TLS stack into your program, which provides more or less this kind of isolation. Firefox does this, for instance. As a general matter, in any setting where you get your TLS stack from a third party, you have to deal with cases where the stack gets upgraded. This can be an issue even if no application using the stack changes. If there are multiple TLS-using apps sharing the same stack that need different configurations, then that is an issue that needs to be managed at an application level. In the specific case here, there seem to be two main avenues: - Configure the TLS stack globally to a maximum 1.2 and then have the new application turn 1.3 on. - Have each individual stack be configured to a maximum of TLS 1.3 (I would expect most stacks to operate this way by default) and have the old applications disable TLS 1.2. It's also not clear to me what's IoT/OT-specific about this scenario, except to the extent to which it's somewhat more likely that the existing deployments haven't already upgraded to a TLS 1.3-capable stack and so haven't had to address these issues, whereas other deployments have already done so. I agree that if you are dependent on a stack which does not support TLS 1.3 it is a pain to add a new stack. That's why I asked you for an example of a real-world system where you would need to deploy a new protocol (i.e., one the IETF has yet to standardize) but not realistically be able to upgrade your system to a TLS 1.3 capable sack. > 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'm not sure what you're proposing here. As noted above, most TLS stacks *do* permit configuration by the application. > 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. I think it's most useful focus on what I think are the main points. -Ekr On Wed, Apr 9, 2025 at 8:53 PM Toerless Eckert <t...@cs.fau.de> wrote: > 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
