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

[Daniel Kahn Gillmor <[e-mail]>]

On 10/24/2014 09:37 AM, Viktor Dukhovni wrote:

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

arguably, there are many such "grossly-misconfigured peers" right now
with respect to RC4 (usually because of misguided attempts to protect
against BEAST, aiui).  These are servers that support something other
than RC4, but select RC4 if a client offers it (even if it was the
client's lowest priority).

So the safest OS approach in the context of a strongly-deprecated cipher
$WEAK_CIPHER, for a client that is willing to ultimately fall back to
cleartext would be, for any given peer P:

 * connect to P and offer TLS without $WEAK_CIPHER
 * if that fails with "no cipher overlap", then:
    * reconnect to P and offer TLS with $WEAK_CIPHER
    * if that fails for any reason, then:
        * reconnect to P with cleartext.

This could probably be further improved by remembering which level of
fallback succeeded on previous attempts, and refusing to fallback further.

I don't think that any of this needs to go in the current draft, though.
 We should be explicitly and unambiguously rejecting RC4, and people
doing TLS-that-is-willing-to-fall-back-to-cleartext can just muddle
along violating the RFC, since they're not even claiming to make the TLS
communications property guarantees to their users anyway.

	--dkg