On Tue, Aug 4, 2015 at 10:35 AM, Martin Thomson
<[email protected]> wrote:
> On 4 August 2015 at 10:24, Wan-Teh Chang <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
