Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02

[Nikos Mavrogiannopoulos <[e-mail]>]

On 10/23/2013 12:49 PM, Eric Rescorla wrote:

>     * Adding a new cipher in stream or AEAD mode?
>     The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing
>     implementations and can be combined with the existing MAC algorithms in
>     TLS (i.e., HMAC-SHA1). That is not the case in the
>     draft-agl-tls-chacha20poly1305-02 draft, where a single combination is
>     registered (of chacha with poly1305). Adding additional combinations in
>     the latter draft would require defining more AEAD modes, something that
>     could be a significant barrier that prevents its implementation (in
>     contrast with just replacing a cipher in the stream setting of TLS).
> 
>     While I understand that there is quite some argumentation for using the
>     AEAD mode in TLS for every cipher/mac combination I don't find it
>     particularly convincing. In this specific case the AEAD mode adds 8
>     bytes of explicit nonce to the TLS record packet without providing any
>     clear advantages compared to the original stream cipher interface.
> I don't believe that this is correct. That is how the GCM cipher suites
> are constructed, but it isn't required by RFC 5246, which says:

Indeed, and it seems the chacha draft didn't use the explicit IV anyway,
so I wasn't correct here. So I only don't get what is the advantage of
that mode. The stream interface of TLS is easier to extend with new
cipher/mac combinations without having to define again or differently
the details of a new AEAD mode (TLS stream mode defines how
authenticated-encryption is performed anyway, and there are no known
issues with that).

Thus from an implementer point of view I find the usage of the stream
mode the natural thing to do, unless something very special needs to be
done, or the cipher/mac combination is so tightly combined like GCM that
warrants the usage of the AEAD interface.

regards,
Nikos