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

Viktor Dukhovni <> Fri, 24 October 2014 13:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0885F1A00B0 for <>; Fri, 24 Oct 2014 06:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id StsglDJ7f6oj for <>; Fri, 24 Oct 2014 06:37:31 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27E501A007B for <>; Fri, 24 Oct 2014 06:37:31 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 387AC2AB109; Fri, 24 Oct 2014 13:37:29 +0000 (UTC)
Date: Fri, 24 Oct 2014 13:37:29 +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)
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 13:37:33 -0000

On Fri, Oct 24, 2014 at 02:07:51AM +0100, Stephen Farrell wrote:

> Yep. I badly write:-) Fair comment though, I wasn't clear so
> apologies. As you guessed, what I meant was:
>   OS is a fine design pattern. Algorithms can be considered-good
>   or dodgy. AES is considered-good. RC4 is dodgy. OS requires
>   considered-good algorithms (I think).

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.

Thus, for example, if we're doing STARTTLS with SMTP, the handshake

	C: EHLO amnesiac.example
	S: 250-smtp.example
	S: 220 make my day
	C: <TLS client HELLO (with some cipher list)>
	S: <TLS server HELLO (with chosen "best" shared cipher) or else fatal TLS alert!>

The client and server commit to TLS without any prior knowledge of
what cipher suites they might share in common.  If the client's
list is too strict, the server will abort with a TLS alert.  Since
we were willing to send in cleartext had the server not indicated
STARTTLS, any cipher suite (even dodgy) is better than a handshake

Even if years later some TLA recovers the plaintext after a
crypt-analytic breakthrough finally renders the dodgy vulnerable
at reasonable cost.

The alternative is either cleartext transmission or failure.  The
former is immediately available to the TLA.  The latter is not what
the opportunistic client "signed up for".  It was just trying to
deliver the mail with as much security as is available, but no

Therefore, opportunistic TLS needs to be more permissive.  With
opportunistic TLS stricter policies are counterproductive.

Leaving a cipher suite out is only practical once it is no longer
the best shared cipher with any peers.  Thus we can if we wish
disable EXPORT cipher suites since they are now never used, but it
serves no purpose to do so (they are never used) beyond perhaps
preventing accidents in which a grossly misconfigured peer selects
EXPORT despite having better options.  I have never observed such
an accident.