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

On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario <hkario@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
>
>