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

[Nikos Mavrogiannopoulos <[e-mail]>]

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.

There have been quite some discussions about that with the TLS WG chairs
as well. I'll provide my point of view here. The need for an alternative
to Poly1305 hash is for redundancy and being conservative when
introducing a new hash (we always had HMAC-SHA1 in addition to
HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design is
implementation simplicity, and definition simplicity. I elaborate below.

There are several market segments. Some make products that last less
than 2-3 years and after that they are obsolete and unmaintained. That
market segment has the luxury to adopt new technologies quickly and
ignore any issues on a 10 year old mobile phone for example. 

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.

This provides rationale why I feel that a backwards compatible with TLS
1.0 and TLS 1.1 ciphersuite is needed that can replace RC4. 

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.
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. Then implementers would
have, implement my special design and release. You could argue that I
could specify it to be exactly the same as the stream
authenticated-encryption and shortcut some of that path... Isn't that
what I'm doing? If there was commonly accepted form of AEAD that would
allow to combine a stream cipher and a MAC, that would change things,
but there isn't.

regards,
Nikos