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

[Watson Ladd <[e-mail]>]

On Fri, Oct 3, 2014 at 2:20 AM, 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.
>
> 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.

Right conclusion: wrong reasons. Carter-Wegman MACs are
unconditionally secure, but the code changes are minimized by reusing
a MAC.

Unfortunately the draft bobbles nonce handling: it's not clear to me
how the nonce is generated in TLS 1.1 and TLS 1.0.
>
> 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 l
> 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.

There is: encrypt then MAC, using two different keys and the same
nonce. This has been known for at least 20 years.

>
> regards,
> Nikos
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin