Subject: [TLS] Some questions about TLS False Start and symmetric ciphers.

From: Fabrice Gautier <[email-masked]>
Date: Wed, 8 Jan 2014 13:59:12 -0800

Hi all,

A couple questions:

1) http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 is a
few years old. Was there any intent to make this an actual RFC at some
point ?

2) What was the rational for leaving some symmetric ciphers out of the
white list.
In particular, why was 3DES not part of the whitelist, and should RC4
still be on the whitelist ?

My understanding is that the purpose of the whitelist was that an
attacker would not be able downgrade to a trivially brute forceable
cipher (e.g.: NULL, single DES...).
My understanding is that even the best attacks on 3DES and RC4 still
require an attacker to capture many messages, so that capturing a
single encrypted message due to false start does not give you much
advantage.

Or putting it another way: If a cipher is considered not good enough
for False Start, why would it be good enough for TLS without False
Start ?

Thanks

-- Fabrice

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Jan 2014 17:12:26 -0500

> still be on the whitelist ?

Nothing deep. 3DES just isn't in my mental model of ciphers most of
the time. RC4 is likely to get removed from the list of False Start
acceptable ciphers soon (in Chrome at least).

> for False Start, why would it be good enough for TLS without False

It probably wouldn't be. However, clients may wish to support poor
ciphers because they would rather inter-operate with a server that
would choose them, than simply not work. But we still wouldn't want
enabling a poor cipher to potentially cause problems with every
server.

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 09 Jan 2014 09:41:33 +0100

> single encrypted message due to false start does not give you much

It doesn't give you much advantage with the currently known attacks.
Unfortunately attacks only get better with time and being conservative
in design pays off.

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 9 Jan 2014 10:39:31 +0100

> few years old. Was there any intent to make this an actual RFC at some

Yes.  There just hasn't been anything essentially new to say for the spec,
and the philosophical problem that we ran into remains -- while False Start
works without problems with the huge majority servers (even though they
haven't been specifically written for it) and is also used a lot in
practice, it appears that some server implementors insist that they
wouldn't like to be bound by *having* to interoperate with that.  While
otherwise we could bootstrap False Start compatibility by, say, making it a
formal requirement with certain new ciphersuites or new TLS extensions,
this unfortunately makes it hard to proceed with meaningful standardization
(other than by waiting for TLS 1.3).  With a bit of express working group
enthusiasm, I could be enticed to create a new I-D version to at least
formally un-expire it for now, though.

> single encrypted message due to false start does not give you much

As Adam has pointed out, we really should be removing RC4 from the
suggested whitelist now.  (3DES has less than 128 bits of security, which
was the reasonable even if somewhat arbitrary threshold we picked.)  Note
that thinking that it's only about a *single* message is, these days at
least, at trap -- clients could easily try to send the same secret over
many independent connections that they try to establish with the same
server.  If that cipher is merely a "fallback" cipher that the real server
wouldn't have picked voluntarily (given the other options offered by the
client), this could weaken security.

> for False Start, why would it be good enough for TLS without False

Because without False Start, you have authenticated confirmation from the
server that the cipher is good enough for that server.

Bodo