On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich <rs...@akamai.com> wrote: > > Personally, I would rather see the nonce construction follow the form > > defined in the respective TLS version. [DB: Adding back in for context: > "That means including redundant bytes in TLS 1.2 and only getting the full > advantage when we move to TLS 1.3."] > > Yes, consistency. +1 >
I think this already came up: https://www.ietf.org/mail-archive/web/tls/current/msg16365.html This is a waste of bandwidth. Consistency is generally good, but a weak argument here. The complexity is minimal. If you don't care about decrypting in-place, none of this matters. If you do care, you already have to deal with: - RC4 and TLS 1.0 CBC use no prefix on the ciphertext - AES-GCM, TLS 1.1+ 3DES use an 8-byte prefix - TLS 1.1+ AES CBC use a 16-byte prefix Adding a 0-byte prefix cipher doesn't make anything worse. It already must vary. As for following what's defined in TLS 1.2, RFC 5246 just says that GenericAEADCipher has a nonce_explicit field and: Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. It then describes the 1.2 AES-GCM scheme, but prefaced with "In many cases, it is appropriate to [...]". Saying nonce_explicit is empty and the nonce is built from the sequence number is perfectly consistent here. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
