Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

[David Benjamin <[e-mail]>]

On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich <[e-mail]> wrote:

> > Personally, I would rather see the nonce construction follow the form
> > defined in the respective TLS version. [DB: Adding back in for context:
> "That means including redundant bytes in TLS 1.2 and only getting the full
> advantage when we move to TLS 1.3."]
>
> Yes, consistency.  +1
>

I think this already came up:
https://www.ietf.org/mail-archive/web/tls/current/msg16365.html

This is a waste of bandwidth. Consistency is generally good, but a weak
argument here. The complexity is minimal. If you don't care about
decrypting in-place, none of this matters. If you do care, you already have
to deal with:

- RC4 and TLS 1.0 CBC use no prefix on the ciphertext
- AES-GCM, TLS 1.1+ 3DES use an 8-byte prefix
- TLS 1.1+ AES CBC use a 16-byte prefix

Adding a 0-byte prefix cipher doesn't make anything worse. It already must
vary.

As for following what's defined in TLS 1.2, RFC 5246 just says that
GenericAEADCipher has a nonce_explicit field and:

   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.

It then describes the 1.2 AES-GCM scheme, but prefaced with "In many cases,
it is appropriate to [...]". Saying nonce_explicit is empty and the nonce
is built from the sequence number is perfectly consistent here.

David