Re: feedback requested regarding deprecation of TLS 1.0/1.1

[Jacob Bachmeyer <jcb62281 () gmail com>]

Steffen Nurpmeso wrote:
> Jacob Bachmeyer wrote in
>  <66C2ACB0.2040203 () gmail 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