On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:
> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > >In practice security improves more when you raise the ceiling, rather the
> > >floor.
> >
> > Let’s start with mandating support of
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for the remaining TLS 1.2
> > implementations. RFC 7540 did this 6 years ago, and it was not a day
> > too late.
>
> I don't understand the motivation. Why not deprecate all of the RSA cipher
> suites?
If you mean all the RSA key exchange suites, sure where that's a viable
choice. It was already argued upthread that this needs to be done
before or as part of deprecating FFDHE, lest the latter just lead to
reversion to RSA key exchange.
This would be a rather drastic floor-raising exercise, possibly in
excess of the present ceiling in some market niches. The results
are not always what we want or expect.
As suggested above, it may first be prudent to specify some MTI
ECDHE ciphers, and check that these are being widely and correctly
implemented and deployed in some of the less familiar places that
have not done so already.
If there are major code size or other resource limits that preclude
support for both FFDHE and ECDHE, or even ECDHE alone, little is likely
to be gained by specifying that the floor is now 2 feet above the
ceiling.
I realise that my focus primarily on the ceiling and not the floor is
not universally shared, and may even be heretical in some circles, but
whether or not it should be the dominant concern, it surely warrants
some thought, because otherwise you do eventually run out of room in
between.
So my take is that barring emergencies, deprecations mostly take care of
themselves, because the better options are compelling and preferred by
default. Such emergencies aside, deprecation can happen once "nobody"
is using an algorithm, not only on the web, but more broadly across all
the market sectors that consume IETF technologies.
Today, I sent Wietse a patch set that disables "medium" ciphers in
Postfix by default and requires TLS 1.2 (rather than 1.0) when TLS is
"mandatory" (submission, DANE, or other destination-specific policy).
I hope it will be merged in time for Postfix 3.6.
At this point, systems using TLS 1.0, SEED, RC4, IDEA or 3DES in SMTP
TLS are rare, and not expected to peers for mandatory TLS. The ceiling
has been high for quite some time, and the floor raising is just a
formality. Also, I'm just changing default settings, not removing
functionality. If someone still needs the legacy crypto in some
dusty corner of their network, I'm not going to stop them.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
