[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66C2ACB0.2040203@gmail.com>
Date: Sun, 18 Aug 2024 21:23:44 -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
Peter Gutmann wrote:
> Jacob Bachmeyer <jcb62281@...il.com> writes:
>
>> The AtE mode has problems, but is still supported in TLS1.2. (Why was EtA
>> not also introduced in TLS1.2?)
>>
>
> It was:
>
> https://datatracker.ietf.org/doc/html/rfc7366
>
> So you don't need any new modes, just an extension to signal its presence and
> swapping the order of the processing operations if present.
>
I see. TLS1.2 supports *both* AtE and EtA.
My question (here expressed yet another way) still stands unanswered:
excluding cipher suites (and the use of concatenated SHA1+MD5) what, if
any, parts of TLS1.0/1.1 are not also required to implement TLS1.2?
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?
-- 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.
