Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt)

[Hubert Kario <[e-mail]>]

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