Subject: Re: [Cfrg] Salsa20 stream cipher in TLS

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Mar 2013 05:36:24 +0000

Geoffrey Keating <[email-masked]>

>It also lets you do GCM, which has performance benefits over AES+SHA1.

It does?  GMAC is kind of a pig unless you've got hardware assist... and
speaking of hardware, if you're using an ASIC for it you don't have much
choice, it's mostly HMAC-SHA1 only.  Even with that aside, anyone who's really
worried about performance seems to be using RC4.

>So are we now in a catch-22 where no-one will upgrade because they don't need
>to because all the fixes are shoehorned into the current version because no-
>one will upgrade?

I'm not sure I'd characterise it as "shoehorned", a better view would be that
the existing versions fix pretty much everything that needs fixing except the
MAC-then-encrypt problem, and given that 1.2 is such a huge change that it's
almost a new protocol in parts (the change from 1.1 to 1.2 is much bigger than
the change from SSL to TLS), it's not surprising that there's no great rush to
move to it.

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.

Kinda scary when you look at it like that...

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 21 Mar 2013 11:26:31 +0100

> 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