[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66C02F68.1050609@gmail.com>
Date: Sat, 17 Aug 2024 00:04:40 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
CC: Neil Horman <nhorman@...nssl.org>
Subject: Re: feedback requested regarding deprecation of TLS
1.0/1.1
Jeffrey Walton wrote:
> On Fri, Aug 16, 2024 at 10:01 AM Jacob Bachmeyer <jcb62281@...il.com> wrote:
>
>> Hanno Böck wrote:
>>
>>> Hello,
>>>
>>> I have no particular insight on the prevalence of TLS 1.0/1.1 these
>>> days, but I want to make a more general comment.
>>> My impression of OpenSSL is that it has a strong tendency to ship
>>> "bloat", i.e., features that either barely anyone needs, but that still
>>> get added (remember Heartbeat extension?), or that should've been
>>> deprecated long ago.
>>>
>>> If this effort to deprecate old protocols is a sign that this is
>>> changing, I welcome this. I'd recommend to have a look at other things
>>> in the OpenSSL codebase that should be trimmed.
>>>
>>>
>> That actually raises another question: what is actually to be gained
>> from deprecating TLS1.0/1.1? Did the protocol significantly change or
>> is the only major difference new cipher suites?
>>
>
> The big selling point of TLS 1.2 is the authenticated encryption
> modes, like CCM and GCM. Prior to TLS v1.2, SSL and TLS relied solely
> on Authenticate then Encrypt (AtE), which was provably secure under a
> couple of constructions. Otherwise it leaked information. At TLS v1.2,
> proper Authenticated Encryption modes became available. CCM and GCM
> are provably secure, and do not leak information due to the ways the
> ciphers are combined.
>
Those are good reasons to support TLS1.2 and to use only Authenticated
Encryption modes over the open Internet. But TLS1.2 also includes
cipher suites not using Authenticated Encryption, so you still need to
support the two-layer AtE protocol form that was used with TLS1.0/1.1.
> If SSL/TLS used Encrypt then Authenticate (EtA) like IPSec, then a lot
> of the troubles would have been sidestepped. Also see Krawczyk's The
> Order of Encryption and Authentication for Protecting Communications,
> <https://www.iacr.org/archive/crypto2001/21390309.pdf>.
>
The AtE mode has problems, but is still supported in TLS1.2. (Why was
EtA not also introduced in TLS1.2?)
>> In other words, what non-trivial code paths would dropping TLS1.0/1.1
>> entirely allow removing? (Concatenating SHA1+MD5 is trivial.)
>>
>
> As far as I know, MD5+SHA1 is used in two places. [...]
>
Yes, but the support for it is trivial. What, if any, non-trivial code
paths could *actually* be removed if support for TLS1.0/1.1 were removed?
In other words, what *actual* benefit towards hardening OpenSSL is to be
had by completely removing TLS1.0/1.1?
-- 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.
