On Tue, Aug 4, 2015 at 10:35 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 4 August 2015 at 10:24, Wan-Teh Chang <w...@google.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls