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

[Wan-Teh Chang <[e-mail]>]

On Tue, Aug 4, 2015 at 10:35 AM, Martin Thomson
<[e-mail]> wrote:
> On 4 August 2015 at 10:24, Wan-Teh Chang <[e-mail]> wrote:
>> The consistency you want to see seems to be
>> consistency with the AES GCM cipher suites, rather than with TLS 1.2.
>
> Yes, this is correct.
>
> RFC 5288:
>              struct {
>                 opaque salt[4];
>                 opaque nonce_explicit[8];
>              } GCMNonce;
>
> RFC 6655:
>                        struct {
>              opaque salt[4];
>              opaque nonce_explicit[8];
>                        } CCMNonce;
>
> Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS
> only (if I'm reading it correctly).

I don't see that special handling for DTLS in RFC 6655. The only
DTLS-specific statement in RFC 6655 is the clarification on how
to build a 64-bit seq_num:

   In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
   48-bit seq_num.

So I am afraid that you read it incorrectly.

It doesn't seem useful to be consistent with the AES GCM and CCM
cipher suites. In my experience implementing both ChaCha20+Poly1305
and AES GCM cipher suites in TLS 1.2, the lengths of the explicit
nonce can be easily parameterized.

I am now inclined to support adopting the draft-TLS 1.3 nonce
mechanism for TLS 1.2. Specifically, this means in TLS 1.2,
ChaCha20+Poly1305 has these parameters:

SecurityParameters.record_iv_length = 0  // zero-length explicit nonce.
                                         // No change from
                                         // draft-ietf-tls-chacha20-poly1305-00.

SecurityParameters.fixed_iv_length = 12  // increased from the value 4 used in
                                         // draft-ietf-tls-chacha20-poly1305-00.

Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.

       struct {
           opaque nonce[12];
       } ChaChaNonce;

      1. The 64-bit record sequence number is padded to the left with
         zeroes to 96 bits (12 octets).
      2. The padded sequence number is XORed with either the
         client_write_IV (when the client is sending) or the
         server_write_IV (when the server is sending)
      3. Store the XOR result in ChaChaNonce.nonce.

Wan-Teh