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

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 <ekr@rtfm.com> wrote:

>
>
> 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
>>
>>
>