Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Viktor Dukhovni <[e-mail]>]

On Mon, Jul 27, 2015 at 09:48:08PM +0100, Stephen Farrell wrote:

> Put another way, if we all agreed that rc4 can likely be routinely
> deciphered in N years and if we further agreed that there are a lot
> of plaintexts that will still be sensitive in N years, then there is
> no great difference today between sending cleartext and rc4
> ciphertext, when we consider highly capable adversaries who record
> ciphertext, and we know those exist even if we do not know quite
> how much ciphertext they record, for how long.

There are two differences.  

    1. It seems unlikely that recovery of every captured RC4 stream
    will become practical, even if recovery of targetted streams
    becomes practical.

    2. After STARTTLS, failing to negotiate RC4 when the peer only
    supports RC4 requires "fallback", not just staying with cleartext
    (which happens when STARTTLS is not offered).  Not all peers
    support "fallback", and we want to avoid that anyway.  So if
    dropping (say) RC4 from OS leads to enough undeliverable email
    to make OS unattractive to users, we win the battle, but lose
    the war.

Fallbacks are bad, complicate code, and lead to various new downgrade
attacks.  It is better, to have an interoperable TLS stack, than
one that sets the bar too high, and then tries to recover by moving
it lower (often much lower than necessary and sometimes under
spuriously).

Avoiding "fallback" to cleartext (as opposed to not trying to do
encryption in the first place) is I think a greater priority than
avoiding weak algorithms when one happens to be encrypting.

-- 
	Viktor.