TLS AEAD ciphers: more bytes for key_block than needed

[maximmasiutin]

TLS AEAD ciphers: more bytes for key_block than needed.

This pull request fixes the issue "More bytes are generated for key_block than needed for AEAD ciphers". In doing the fix, I have reused existing code that was already calculating IV length within the key block. See the discussion at #12007 for more details. It was the idea of @jwalch to use the existing code. I have taken existing code using the so-called "extract function" refactoring pattern. After that, @richsalz has proposed to optimize the code that by removing "k", and just replacing the assignments with return statements, then removing the "else".

This pull request is basically about the two things:

(1) Enables tracing of the key block length to show the bug by adding 'BIO_printf(trc_out, "key block length: %ld\n", num);'
(2) Fixes the bug by creating a function 'tls_iv_length_within_key_block' from existing code and calling it from that old place and from a second (new) place where IV length was taking regardless its context within the key_block.

I have also changed the order of addendums to correspond to one given in the RFC. The old order was somewhat counter-intuitive.

Old:

num = EVP_CIPHER_key_length(c) + mac_secret_size + EVP_CIPHER_iv_length(c);

New:

num = mac_secret_size + EVP_CIPHER_key_length(c) + tls_iv_length_within_key_block(c);

Here is the order in the RFC:

client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]

So, MAC_key comes first, then come cipher key and then the IV. That's why I put "mac_secret_size" first.

@mattcaswell - please review.

Fixes #12007

[t8m]

Could you please amend the commit message to be more descriptive and put the Fixes line in the commit message body not on the first line? Use git commit --amend and then git push --force to do that.

[t8m]

Unfortunately the formatting is less than perfect. There are missing line separators. For example the Fixes #12007 should be alone on a separate line and without the parentheses. Also the first line should be as concise as possible - something like: TLS AEAD ciphers: do not generate more bytes for key_block than needed

[t8m]

Also the message body does not need to include the history of the changes and it usually is not written in first person, but it also does not hurt so that is up to you.

[maximmasiutin]

@t8m I have updated both the pull request description at the github and also the git commit description. It is now multiline. Can you please confirm that it is now OK?

[t8m]

LGTM if @mattcaswell also approves.

[openssl-machine]

This pull request is ready to merge

[t8m]

Merged to master. Thank you for the PR.