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

[Bodo Moeller <[e-mail]>]

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

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.



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

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.


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


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

Bodo