Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item

[Brian Smith <[e-mail]>]

Nikos Mavrogiannopoulos <[e-mail]> wrote:
> On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote:
>> HI Nikos
>>
>> A pre-1.2 implementation of ChaCha20 assumes that there are libraries
>> out there that on the one hand don’t have TLS 1.2, and on the other
>> hand are still actively developed enough that they will implement a new
>> algorithm. I don’t think that’s the case. If ChaCha20-Poly1305 is going
>> to be implemented in OpenSSL, it’s going to be in 1.0.1 or 1.0.2. I
>> don’t think anyone’s going to add it to 0.9,8, where every recent patch
>> has been a security hotfix. Similarly, every library I know of that is
>> being maintained already has TLS 1.2.  I don’t feel strongly about it,
>> but I don’t see the use of having new non-AEAD ciphers at this point.

I agree with this. The ChaCha20-HMAC-SHA-1 cipher suite is not a good
use of resources and should be removed so we can focus on other, more
important, improvements.

> The market segment I work on makes products that are designed to last
> for 6+ years (often more than 10) and during that time they are
> maintained and get new security features whenever that's possible. While
> adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding
> support for TLS 1.2 or AEAD is significant work with many potential
> side-effects and regressions, and that is something you don't do on a
> production system unless there is a real reason for that.

There are real reasons to add support for TLS 1.2 to stable products
like RHEL (in particular). For example, versions less than 1.2 rely on
the collision resistance of MD5 and SHA1, which really a bad idea.
Further, nobody would be able to deploy HTTP/2 effectively (i.e. works
with most browsers) without TLS 1.2, unless their products avoid the
system crypto stack, which is counter to the purpose of having a
system crypto stack in the first place. Consequently, I think it makes
a lot more sense to spend time to figure out how to spread TLS 1.2 to
these more conservative products and deployments, than it does to
spend time figuring out how to avoid doing so.

Further, why would any user that is too change-averse to deploy TLS
1.2 want to deploy ChaCha20 cipher suites?

> The other reason I believe that ChaCha20-SHA1 is needed, is redundancy
> and backup. Poly1305 is a new MAC algorithm not used anywhere else, and
> having a conservative design along it, provides a reasonable fallback.

We already have the AES-based cipher suites for fallback.

> Why this design uses the TLS stream authenticated encryption? because it
> is simpler and safer. The TLS stream authenticated encryption is a tried
> and proved construction that combines a MAC and a stream cipher. By
> going the AEAD path I'd have to play cryptographer and define a "novel"
> Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to
> standardize it as AEAD (possibly pass through CFRG as well), and few
> years later when it is obsolete add it to TLS.

You had to do the same thing for the stream construction. See
https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03#section-5
where you redefine the stream construction.

> Then implementers would
> have, implement my special design and release.

Who is planning to implement ChaCha20-SHA1, regardless of how it is
specified? I expect very few people to do so.

Also, some newer implementations of TLS may not even implement the
stream mode construction at all, since currently it is used only for
RC4. This makes it even less likely that implementations will support
the HMAC-SHA1 version.

Cheers,
Brian