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

[Adam Langley <[e-mail]>]

On Wed, Oct 23, 2013 at 5:33 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made
> efficient in hardware, in our opinion the performance benefits don't
> justify switching from a winner of an international competition to
> another algorithm (even if it is a derivative of it).

I don't think that there's much between them, but have a slight
preference for ChaCha, which mirrors the CFRG: "The RG expressed a
preference for ChaCha." [1]

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10221.html

> * Applicability to Datagram TLS
>
> The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not
> DTLS. That is because its combination with poly1305-chacha results to an
> RC4-like effect where rearranged or lost packets result in a
> desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies
> to both TLS and DTLS (this results from the choice of having the block
> cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main
> reason (for me at least) for draft-josefsson-salsa20-tls-02.

I don't believe that this is correct. There is no state carried
between encryptions of records. Given the sequence numbers of a set of
records, they can be processed in any order.

Although the ChaCha draft doesn't mention DTLS, I don't think there's
any fundamental difference here.

> 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.

This is incorrect, there is no explicit nonce in the ChaCha AEAD construction.

Chrome is conducting experiments at the moment to test the
transparency of the general Internet to TLS 1.0 and 1.2, although it
will take a few months for the results. If TLS 1.2 turns out to be
non-viable then I agree that some changes will be needed somewhere,
but I'm still awaiting that data.

> Both drafts introduce a universal hash based MAC. However, the
> chacha-poly1305 draft uses the encrypt-then-authenticate (EtA)
> construction while the salsa20 draft uses TLS' authenticate-then-encrypt
> (AtE) construction. When combined with ideal ciphers and MAC algorithms
> both modes can be equivalent. However, the AtE construction has the
> advantage of not revealing the MAC nor the authenticated data to an
> adversary. Interestingly enough the only known attacks on universal hash
> based MACs require access to MAC and data [1]. That is, these attacks
> (the key guessing and the divide and conquer) do not directly apply to
> draft-josefsson-salsa20-tls-02.
>
> Of course these attacks are of high complexity and impractical (unless
> some other weakness in the TLS protocol, or the MAC algorithm is found),
> but they nevertheless reinforce the view that the AtE construction has
> advantages on non-ideal MAC algorithms.

On the other hand, EtA allows for faster forgery rejection which,
while not so useful for TLS, is useful for DTLS.

In any case, I don't believe that the security bounds laid out in the
original Poly1305 paper[2] have been altered and I believe those
bounds are sufficient for all users of (D)TLS.

[2] http://cr.yp.to/mac/poly1305-20050329.pdf


Cheers

AGL