On Tuesday, 10 July 2018 16:03:24 CEST Eric Rescorla wrote: > On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario <hka...@redhat.com> wrote: > > On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote: > > > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > > > > Is there any reason why we wouldn't also consider deprecating cipher > > > > suites we don't like? For instance, RFC 5246 mandates the > > > > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably > > > > agree isn't ideal for several reasons. > > > > > > Is the objection primarily to AES-128-CBC or to RSA key exchange? > > > With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > > > outperforms AES-256-CBC, and the various CBC issues are resolved > > > via EtM. > > > > > > > The ECDHE suites with AES-GCM > > > > are widely available, perhaps widely enough that we might consider a > > > > stronger move and update 5246 to modern suites. > > > > > > More generally, as noted in RFC7435, you get more security by raising > > > the ceiling than by raising the floor. Breaking the ability to > > > communicate with legacy systems may feel satisfying, but does not > > > generally improve the security of the up-to-date systems, barring > > > downgrade issues in the protocol. > > > > The github version of the document points out that the security of TLS 1.2 > > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. > > Well, yes and no. If you allow static RSA, then yes. If you require > (EC)DHE, then the anti-downgrade measures in the TLS 1.3 random values are > intended to protect against downgrade even if SHA-1 is compromised (because > the randoms are signed).
but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
