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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 23, 2013 at 2:33 AM, Nikos Mavrogiannopoulos <[e-mail]>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:

   Each AEAD cipher suite MUST specify how the nonce supplied to the
   AEAD operation is constructed, and what is the length of the
   GenericAEADCipher.nonce_explicit part.  In many cases, it is
   appropriate to use the partially implicit nonce technique described
   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
   the explicit part.  In this case, the implicit part SHOULD be derived
   from key_block as client_write_iv and server_write_iv (as described
   in Section 6.3), and the explicit part is included in
   GenericAEAEDCipher.nonce_explicit.

With that said, the argument for having an explicit IV is as follows: it's
desirable to have a cryptographic AEAD primitive which doesn't
accidentally enable nonce reuse. In order to do this, you need to
internally generate the nonce, which means it must be explicit.
(For FIPS purposes, this means it must be generated inside the crypto
boundary). That's why the GCM algorithms were done this way.

You may or may not subscribe to this, but it's basically
an orthogonal question to the rest of these issues.

-Ekr