Re: [TLS] ban more old crap

Viktor Dukhovni <> Sat, 25 July 2015 19:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F5CC1ACE11 for <>; Sat, 25 Jul 2015 12:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id msRsfAg4aAjh for <>; Sat, 25 Jul 2015 12:18:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFBB61ACE03 for <>; Sat, 25 Jul 2015 12:18:46 -0700 (PDT)
Received: by (Postfix, from userid 1034) id C352C284B64; Sat, 25 Jul 2015 19:18:45 +0000 (UTC)
Date: Sat, 25 Jul 2015 19:18:45 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] ban more old crap
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Jul 2015 19:18:48 -0000

On Sat, Jul 25, 2015 at 03:00:54PM -0400, Dave Garrett wrote:

> On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote:
> > I would go further, and say that "prohibiting RC4" in any sense
> > that is more than prohibiting its use as the final outcome of a
> > handshake would be a rather counter-productive strategy.
> > 
> > Servers and clients are strongly encouraged to not choose it, but
> > to reject connections from peers that offer it for interoperability
> > with others would just create a mess that would be operationally
> > challenging.  RC4 is dying, just let it fade away into insignificance.
> I agree. The current draft language of not offering or negotiating
> RC4 is fine, as-is. My proposal of stopping tolerance of garbage
> suite offers is just for <112-bit junk.

If you mean the export suites plus the non-export single-DES suites
(these are only suites that I know to meet the above criterion),
and the idea is to refuse client connections when these are offered,
that's still rather aggressive.

Is that really necessary?  The browsers will disable these through
software updates, consumers don't configure browser cipher suites.

For non-browser applications, a lot of administrators would face
mostly unnecessary interoperability issues and would have to
reconfigure client systems to disable cipher suites already disabled
on the server end.

Is the benefit worth the cost.  They'll upgrade their systems to
ones that don't implement these features in due course without