On Tuesday, 10 July 2018 18:01:50 CEST Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote: > > 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. > > Is this accurate? TLS 1.0 uses a combined SHA-1 + MD5 PRF. Are > there known attacks that compromise TLS 1.0 via collisions in its > PRF?
that's what SLOTH was about (among other things) > [ IIRC, one embarrassing feature of TLS 1.2 vs. TLS 1.0 is that in making > the signature algorithms negotiable, it became possible to offer and > use MD5 where previously TLS 1.0 used SHA-1. ] > > > that is the downgrade issue in the protocol > > Keep in mind that my example, illustrating potentially counter-productive > raising of the floor, was about SHA-1 signatures in certificates. > Does accepting SHA-1 signatures in *certificate chains* create > opportunities to downgrade TLS 1.2 to TLS 1.0? ah, then I misunderstood, sorry for certificates, the answer is "not immediately", and "harder" as that requires either the ability by attacker to get a cert from an internal CA (that it can the calculate collision for) or a preimage attack on SHA-1 signatures (which is significantly harder than chosen prefix) > Absent, such downgrade attacks, what's really needed is broader > support for TLS 1.2 (raising the ceiling), which does not require > removal of support for TLS 1.0 (raising the floor). do we have access to other incentives than breaking compatibility with old stuff? > As a community we're still prone to pursue improved security primarily > through removal of weak algorithms, and under-appreciate security > improvement via the introduction of stronger algorithms. aren't new strong algorithms only effective when they are actually used though? > Of course removal of weak algorithms has its place, if these > facilitate downgrade attacks, or present unnecessary attack-surface > once no longer used. But we should be careful to not rush into > overzealous deprecation that can sometimes do more harm than good. my opinion is that published RFCs should represent _current_ best practice, if only because we will have to live with stuff that is deployed new for 10 years if not more -- 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
