Re: [Cfrg] Salsa20 stream cipher in TLS

[Simon Josefsson <[e-mail]>]

Peter Gutmann <[e-mail]> writes:

> It's also a killer roadblock to any new changes in 1.3.  Since even the most
> trivial change (to get to 1.3) will involve implementing and deploying all of
> 1.2, people will keep adding stuff to 1.1 rather than have to go through the
> pain of 1.2 in order to add new features.  So in that sense you're right,
> we're going to keep seeing changes to 1.1 rather than having them added in
> 1.3.  1.2 is too big a hurdle for too small a gain.

Are people adding stuff to 1.1?  My impression is that all serious
problems (including renegotiation and the explicit IV problem) are
solved in TLS 1.0 too.  The problems are solved through specification
(think renegotiation) or through implementation fixes (think empty
fragments to mimic explicit IVs).

For TLS 1.0 and SSL 3.0 to go away, there needs to be a serious enough
security problem that is not fixable in TLS 1.0 implementations.  I'm
not convinced that will happen.  We have seen that people will try hard
to resolve protocol security problems within TLS 1.0.

Thinking about this, perhaps we need a document explaining how to
implement TLS 1.0 securely.  TLS 1.0 as implemented by RFC 2246 is not
secure.  The document could say that you need to send bad_record_mac in
case of MAC verification failures, and to send empty fragments to combat
CBC attacks, and implement renegotiation, and discuss how to combat CBC
timing attacks, and something about RC4.  And other things I may have
forgotten.

Right now it seems the knowledge about fixing TLS 1.0 are found in TLS
implementations and not discussed in IETF documents.

/Simon