Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade unless you backport the mechanism to your 1.2 implementation, which I expect many people will not do, despite the specs.
-Ekr On Tue, Jul 10, 2018 at 7:03 AM, Eric Rescorla <e...@rtfm.com> 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). > > -Ekr > > >> that is the downgrade issue in the protocol >> >> https://github.com/sftcd/tls-oldversions-diediedie/blob/ >> bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldversions- >> diediedie.txt#L142-L145 >> -- >> 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 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
