nonce of AES-GCM in SSL It seems that the nonce of AES-GCM in SSL has 3 parts:


salt, 4 bytes, generated in handshake, not changed in whole session
nonce_explicit, 8 bytes, chosen by the sender and carried in each SSL record
inner_counter, 4 bytes, used in AES-GCM internal


Is it possible to use a more simple method to construct the nonce:


generate a 16-bytes IV in handshake
use this IV as counter for each cipher block in the whole session life, ignore SSL record boundary


then the sender need not carry nonce for each record, saving the bandwidth.

===

I read the RFCs again and found I misunderstood something.

Let me make the question clear.


AES-GCM algorithm: require the nonce is distinct.
AES-GCM specification [RFC 5116]:


It gives an recommended format (not required):

" When there are multiple devices performing encryption using a single
key, those devices must coordinate to ensure that the nonces are
unique.  A simple way to do this is to use a nonce format that
contains a field that is distinct for each one of the devices, as
described in Section 3.2."     [ Fixed + Counter ]

" In some cases, it is desirable to not transmit or store an entire
nonce, but instead to reconstruct that value from contextual
information immediately prior to decryption."
[ Fixed-Common + Fixed-Distinct + Counter ]
It is defined for protocols that uses record. I missed this before:

"Each AEAD algorithm MUST accept any plaintext with a length between
zero and P_MAX octets, inclusive, where the value P_MAX is specific
to that algorithm.  The value of P_MAX MUST be larger than zero, and
SHOULD be at least 65,536 (2^16) octets.  This size is a typical
upper limit for network data packets."

QUESTION: However if we ignore the specification, is it possible to treat the whole SSL session as a stream (ignore the record bondary), and use only one nonce (and use the nonce as counter) ?

AES-GCM in SSL [RFC 5288]: it uses the recommended format.

QUESTION: since it generates master-secret in each SSL session, it would not hanppen that "multiple devices performing encryption using a single key". Why does SSL use the recommended format (the Fixed part)? What's the function of 'salt'?


I know that since specifications of AES-GCM and SSL have been defined, we should just follow it.
I just wonder why it was defined like this.

Besides, maybe we could define an SSL-extension, so that the SSL client and server could use record-seq as nonce_explicit, and do not send it with record.
This is a trickier question than you might think.

The first thing to note is that your scheme doesn't respect record boundaries. TLS 1.2 seems to have been rewritten to use a random IV for CBC mode encryption for each record (to avoid certain attacks). It is therefore likely that the idea of TLS 1.2 is to respect record boundaries.

The document "AES Galois Counter Mode (GCM) Cipher Suites for TLS" - RFC  5288 - mentions "An Interface and Algorithms for Authenticated Encryption" - RFC 5116. This document specifies the use of a 4 byte salt and 8 byte random. That means that the nonce is 12 bytes total, consisting of the persistent part of 4 bytes and 8 bytes random. The GCM specification strongly recommends a 12 byte (96 bit) nonce/IV. This specification in turn is based on GCM ESP, RFC 4106, which specifies the use of GCM for IPsec. So in general the use of GCM in TLS 1.2 seems to follow previously established standards. 

The specification of a per record random (explicit) part is of course in line with the cipher suites that use CBC based encryption. In this case however the IV only has to be 8 bytes instead of 16, which saves some 8 bytes as overhead. That's still 8 bytes more than your proposed scheme - which, again, doesn't respect record boundaries - but it's better than CBC.

Notes:


If you would change to a fully implicit nonce you should still keep to 12 bytes to keep within the GCM specifications. If you would specify 16 bytes IV then the GCM specification requires an additional GMAC. There seems to be no way of specifying a 16 byte counter to be used; the 4 least significant (rightmost) bytes are set by the algorithm itself.
Related, in your scheme it is impossible to use a GCM API that only allows 12 byte nonces (i.e. without the counter included in the IV). You would need some way of keeping track of the counter and a method of instantiating GCM with that full 16 byte counter.
In your scheme it would be impossible to parallelize encryption/authentication and decryption/verification unless you had a way to pre-compute the record payload.


In conclusion, although your scheme could work (it's more efficient and isn't likely to be insecure), it doesn't respect record boundaries and it would put additional requirements on the GCM library. Finally, it would not follow pre-established standards for the use of GCM in a transport protocol.

In TLS 1.3 (under construction at the time of writing) it seems that the record number may be used instead of the explicit random, which would require less overhead in the record header and less calls to the random generator. 



Note that Figure 2 in RFC 5116 "An Interface and Algorithms for Authenticated Encryption" includes the counter in the nonce specification. I've made a report for an ERRATA on this as the GCM specification and the ESP documents both treat the nonce as a 12 byte value (so without the counter).