[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8ndnyhyMNaQu3N_uUM_yXhd32PwR9odEOeoDe7jC5fQLw@mail.gmail.com>
Date: Fri, 16 Aug 2024 11:23:51 -0400
From: Jeffrey Walton <noloader@...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
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.
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>.
> 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. The first is RSA
signing during key exchange. This one can be problematic:
md5_hash
MD5(ClientHello.random + ServerHello.random + ServerParams);
sha_hash
SHA(ClientHello.random + ServerHello.random + ServerParams);
And:
select (SignatureAlgorithm)
{ case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
But the Server Key Exchange message only needs to survive for as long
as 2-MSL (how long it takes for a packet to be determined lost and
retransmitted, which should be under 2 minutes), so it may only be a
theoretical concern. That is, an attacker is not going to come up with
an existential forgery in two minutes (before the TCP timer expires,
and a new message is transmitted).
The second is the entropy extraction in the PRF function. For the
second use case, collisions don't matter. The thing that matters is
the hash behaves like an ideal hash and outputs a uniform
distribution.
> > I also think there's probably potential to remove some obsolete
> > ciphers (DSA?).
>
> While DSA is definitely obsolete (advances in conventional computing
> have begun to approach the ability to plausibly solve 1024-bit keys, and
> DSA keys *MUST* be 1024-bit, supposedly to facilitate smartcard
> implementations), OpenSSL is also a general cryptographic library and
> applications can use its primitives for other purposes. In particular,
> this means that dropping TLS1.0/1.1 cipher suites does *not* mean you
> can drop the ciphers that were used in those suites.
Jeff
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.
