[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66C53878.9010006@gmail.com>
Date: Tue, 20 Aug 2024 19:44:40 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS
1.0/1.1
Steffen Nurpmeso wrote:
> Jacob Bachmeyer wrote in
> <66C2ACB0.2040203@...il.com>:
> [...]
>
> |Removing support for TLS1.0/1.1 has definite costs in compatibility,
> |costs that hit particularly hard with legacy embedded devices for which
> |no updates will be available. Given that TLS1.2 is to remain supported,
> |what benefits to maintainability are to be had? How much of the
> |TLS1.0/1.1 support does *not* overlap with the TLS1.2 support? How much
> |of it *should* overlap if the code were to be optimally refactored?
>
> [...]
>
> My own gut feeling says btw that no logical argument of whoever
> can change anything on this topic, there is a pimple to go, the
> cancel culture requires a victim, the next announcement (ie web
> page to which the otherwise hollow email message points) shall
> have an effective advertising-niveau-compatible entry.
>
Then I am publicly preparing the "I told you so" in the list archives
for when the illogical act eventually draws consequences, like asset
management tools getting cracked because they include an unmaintained
OpenSSL to talk to legacy devices. (And talking to legacy devices is
expected to be non-negotiable for asset management tools.)
> [...]
>
> So it *could* be "removing support of TLSv1.0 and v1.1" is in fact
> only a small mostly housekeeping diff at first.
>
Which is exactly the reason *not* to remove that support: the
maintainability benefits are negligible, while the costs to applications
that actually need that support are vast.
Restrict negotiating those versions behind special configuration? Sure;
those protocols should no longer be used on the open Internet. Remove
them entirely? That will make problems for exactly the niche
applications that can have obscure and nasty follow-on effects.
> By the way i found your question on additional aka redundant
> checksums (wherever) very interesting, given that Antonio
> Diaz Diaz (author of plzip plus support libraries) swears on
> CRC-32 for long time storage, with absolutely impressive numbers
> on reliability (i think here: [1])
>
> [1] https://www.nongnu.org/lzip/safety_of_the_lzip_format.html#lzma_crc
The other side of using CRC for archives is that all modern storage uses
ECC "behind the scenes" and the CRC might actually be useless if the
underlying ECC would catch all errors the CRC would detect. The
critical difference between an archive checksum and a confounder is that
the errors an archive checksum must catch occur randomly, while a
confounder is hoped to introduce a contradiction to an intelligent
attacker's problem. (In other words, Mallory's cryptanalytic attack
requires flipping bits that will alter the checksum. The
straightforward balancing act to preserve the checksum requires flipping
bits that the cryptanalytic attack cannot accommodate. I do not know
how difficult combining the balancing act into the cryptanalytic attack
would be.)
-- Jacob
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
