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

[Viktor Dukhovni <[e-mail]>]

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

	C: EHLO amnesiac.example
	S: 250-smtp.example
	S: 250 STARTTLS
	C: STARTTLS
	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
failure.

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

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.

-- 
	Viktor.