Make the AES-GCM cipher suites work in DTLS, by moving the

net/third_party/nss/ssl/sslt.h

Index: net/third_party/nss/ssl/sslt.h
===================================================================
--- net/third_party/nss/ssl/sslt.h	(revision 218090)
+++ net/third_party/nss/ssl/sslt.h	(working copy)
@@ -103,7 +103,10 @@
     ssl_mac_sha       = 2, 
     ssl_hmac_md5      = 3, 	/* TLS HMAC version of mac_md5 */
     ssl_hmac_sha      = 4, 	/* TLS HMAC version of mac_sha */
-    ssl_hmac_sha256   = 5
+    ssl_hmac_sha256   = 5,
+    ssl_hmac_sha384   = 6,
+    ssl_hmac_sha512   = 7,

[wtc, 2013/08/17 00:21:15]

Question: to be future-proof, I added ssl_hmac_sha384 and ssl_hmac_sha512.
The sslt.h header is a public header, so the values of these enums cannot
change.

But, given our current opinion of HMAC-SHA256 ciphers, it seems unlikely
that we will implement HMAC-SHA384 ciphers. (I don't know of any
HMAC-SHA512 ciphers.) So perhaps I should not reserve the enums for
ssl_hmac_sha384 and ssl_hmac_sha512 now. What do you think?

Reserving these two enums resulted in two extra entries in the mac_defs
array in ssl3con.c, because that array is indexed by this enum type.

[Ryan Sleevi, 2013/08/17 02:00:23]

My preference would be not to introduce them until they're actually used, and to
deal with the asymmetry then. Given all the performance concerns, and Keccak, it
does seem unlikely to see these used or to provide significant value.

[wtc, 2013/08/19 23:31:56]

Done.

+    ssl_mac_aead      = 8
 } SSLMACAlgorithm;
 
 typedef enum {
@@ -159,6 +162,9 @@
     PRUint16             effectiveKeyBits;
 
     /* MAC info */
+    /* AEAD ciphers don't have a MAC. For an AEAD cipher, macAlgorithmName
+     * is "AEAD", macAlgorithm is ssl_mac_aead, and macBits is the length in
+     * bits of the authentication tag. */
     const char *         macAlgorithmName;
     SSLMACAlgorithm      macAlgorithm;
     PRUint16             macBits;