On Thursday 30 July 2015 15:09:18 Viktor Dukhovni wrote: > On Sun, Jun 21, 2015 at 07:00:55PM +0000, Giuseppe D'Angelo via RT wrote: > > diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod > > index c2d40ac..7fbe3a4 100644 > > --- a/doc/apps/ciphers.pod > > +++ b/doc/apps/ciphers.pod > > @@ -585,10 +585,22 @@ Note: these ciphers can also be used in SSL v3. > > > > =head2 Pre shared keying (PSK) ciphersuites > > > > + TLS_RSA_PSK_WITH_RC4_128_SHA RSA-PSK-RC4-SHA > > + TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA-PSK-3DES-EDE-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA-PSK-AES128-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA-PSK-AES256-CBC-SHA > > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 RSA-PSK-AES128-CBC-SHA256 > > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 RSA-PSK-AES256-CBC-SHA384 > > + TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 RSA-PSK-AES128-GCM-SHA256 > > + TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 RSA-PSK-AES256-GCM-SHA384 > > > > TLS_PSK_WITH_RC4_128_SHA PSK-RC4-SHA > > TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK-3DES-EDE-CBC-SHA > > TLS_PSK_WITH_AES_128_CBC_SHA PSK-AES128-CBC-SHA > > TLS_PSK_WITH_AES_256_CBC_SHA PSK-AES256-CBC-SHA > > > > + TLS_PSK_WITH_AES_128_CBC_SHA256 PSK-AES128-CBC-SHA256 > > + TLS_PSK_WITH_AES_256_CBC_SHA384 PSK-AES256-CBC-SHA384 > > + TLS_PSK_WITH_AES_128_GCM_SHA256 PSK-AES128-GCM-SHA256 > > + TLS_PSK_WITH_AES_256_GCM_SHA384 PSK-AES256-GCM-SHA384 > > Question, should we really be adding new RC4 or new 3DES ciphersuites? > Both ciphers are rather obsolete now. And we even have an RFC that > "bans" RC4. While I have been known to resist potentially premature > removal of *existing* RC4 support, I am certainly not a fan of RC4 > and see no reason to add more RC4 to OpenSSL.
those are PSK ciphers, unless you set up PSK they won't be advertised at all, adding support for them has minimal impact on Internet use (be it port 443 or otherwise) of RC4 and 3DES and for people that actually need this support, it's better that they use OpenSSL than a home-cooked solution by an intern > I am not even sure that adding Camellia is a net win, ideally AES > and (soonish) ChaCha20 are enough. Camellia is the recommended backup cipher by ENISA, rightfully so > One might similarly question the longevity of the new CBC suites, > TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be > used for session resumption in 1.3). I give them 20 years, ok... 30 years tops > How many of the new ciphersuites are used/needed in practice? Which > are MTI for PSK? I think that when adding ciphersuites, we have > the opportunity/responsibility to exercise good judgement and enable > only the essential ones, and try to keep a lid on needless ciphersuite > proliferation. this horse left the barn, the barn got overgrown, people cut the trees and now are building a new barn -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev