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

[Nikos Mavrogiannopoulos <[e-mail]>]

On 10/23/2013 03:55 PM, Adam Langley wrote:

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

As far as I understand you use chacha to generate the keystream for
poly1305. Thus you carry state between records (chacha is a stream
cipher). I don't know if I have missed anything there, but I don't see
resetting chacha with a new IV per MAC calculation.

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

I missed that. Indeed.

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

Is that really an issue? If yes, then EtA isn't also invulnerable to a
DoS attack, it is a big more lightweight.

However, as a general comment I think DTLS' resilience on forged packets
isn't that good. It makes it a perfect target to lay an attack. I think
it would be much better to have a limit by default on the allowed
packets with wrong MAC.

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

Of course, these attacks require another flaw or leak to be practical.
However, my point is, that even with that additional flaw or
information, they will still not be applicable in AtE mode.

regards,
Nikos