Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

Geoffrey Keating <> Fri, 24 October 2014 20:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A3AF1A9107 for <>; Fri, 24 Oct 2014 13:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AHPN3qFobmH0 for <>; Fri, 24 Oct 2014 13:07:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8803F1A1B21 for <>; Fri, 24 Oct 2014 13:07:05 -0700 (PDT)
Received: by (Postfix, from userid 501) id BBF5C33D0E1; Fri, 24 Oct 2014 20:07:04 +0000 (UTC)
Sender: geoffk@localhost.localdomain
References: <> <> <> <> <> <>
From: Geoffrey Keating <>
Date: 24 Oct 2014 13:07:04 -0700
In-Reply-To: <>
Message-ID: <m2h9yts047.fsf@localhost.localdomain>
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt
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: Fri, 24 Oct 2014 20:07:09 -0000

Viktor Dukhovni <> writes:

> When OS is a just-in-case "upgrade" from cleartext to unauthenticated
> encrypted communication, there is requirement for "considered good"
> algorithms.  The prime-directive is to not disrupt communication,
> only then do we try to encrypt if possible.
> Leaving a cipher suite out is only practical once it is no longer
> the best shared cipher with any peers.

Suppose 20% of hosts will use RC4 if it is offered, and 0.1% will
refuse a connection if RC4 is not offered.  Then by not offering RC4,
you are downgrading 0.1% to plaintext (assuming that's what happens)
and upgrading 20% to a secure cipher---in the short term.  I believe
that in itself is likely to be a win overall.

But, some won't go to plaintext, they will instead fail to deliver
mail.  This will cause them to be fixed.  Others will look for a
different relay host, which might support better encryption.  So maybe
it's 0.01%?

And, in the long term, it's more likely that an administrator will
notice the failed SSL attempts than connections which succeed but use
insecure ciphers.

So, I don't think what you're saying is a general rule, and I think it
doesn't apply in this case.