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

[Nico Williams <[e-mail]>]

On Tue, Aug 25, 2015 at 05:21:46PM +0100, Stephen Farrell wrote:
> On 25/08/15 17:06, Viktor Dukhovni wrote:
> > In any case, whether it is RC4 now, or some other deprecated
> > ciphersuite in the futre, with opportunistic security one needs to
> > pay more attention to what interoperates than what is unequivocally
> > strong.  The goal is as much security as can be realistically had,
> > not "all or nothing".  I like to make an analogy with vaccination,
> > we're protecting the infrastructure as a whole, rather guaranteed
> > security for a particular flow.
> 
> Do you agree though that there are at least two points in time
> involved when considering weakened or suspect ciphers?
> 
> There is the time you're discussing of when the bad algorithm
> can be turned off without damaging interop of ciphertext form
> packets.
> 
> But there is also the time after which one considers that all
> such ciphertext will in a short while be almost the same as
> plaintext for a capable attacker.
> 
> And the latter can happen before the former.

We've been pwned, so we want that to stop, and the way we're choosing to
make it stop is to shoot ourselves in the feet.

Less rhetorically:

We know RC4 is weak and we want to use something else that's better
instead.  Clearly, we can ban RC4, but that isn't a magic wand that
makes everyone start using AES or what have you.  Still, we plow on
because hey, some TLS implementors will understand the SMTP OS situation
and won't break that application.  But! if we merrily write text telling
TLS implementors to remove RC4, many of them will, and in the process
they will make security/interop for SMTP demonstrably worse (as Viktor
has shown).

It seems we can't be moderate in how we approach cipher obsolescence,
perhaps because... we're embarrassed to have obsolete ciphers around so
long after they became obsolete?  That's not a good excuse for throwing
a big switch.  A good excuse for throwing the switch is any case where
merely offering weak crypto introduces a downgrade attack, but that's
not the case here.

"Look ma'!, we banned the bad thing" is clever marketing.  For a short
while.  "Look ma'!, we're getting off the old thing and onto the new,
and we're giving people time so we don't make things worst in the
short-term" is a mouthful and ma' will have to think about it before
deciding that we're doing the right thing, but it is the right thing.

We totally can live with an outright ban on RC4.  That not all TLS
implementors will adhere to.  Or accept the loss of security/interop for
SMTP.  If implementors willfully diverge from the spec, then the spec is
probably wrong.  If implementors faithfully implement a spec, and as a
result applications break, the spec is probably wrong.  The only hope
for an outright ban is that breakage causes people to go fix it.  But
with SMTP OS it's not always clear to users that there's breakage, and
when it is clear (mail won't flow) it isn't always easy to go fix it.

Nico
--