[AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-02

[Woo-Hwan Kim <[e-mail]>]

Hi.

Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-02.

1. Typos
Sections 5.2.1, 6. length(plaintext) → length(Plaintext) i.e. plaintext =>
Plaintext
Section 5.2.2. length(ciphertext) → length(Ciphertext) i.e. ciphertext
=> Ciphertext
Section 6. 12 octet IV  =>  12-octet IV
Section 6. ~ to form cipher  =>  to form ciphertext
Section 6(CCM part). 4-octet block counter  =>  3-octet block counter
Section 6(CCM pseudocode). assert len(plaintext) <= 2**28  => ... (2**28-16)
Section 6. keystream of length of up to 2^24 octets for AES-CCM => ...
2^28-16 octgets ...
* In CCM counter starts from 0 and the first block is used for generation
the tag.
Sections 9.1, 10.1 12 octet initialization vector  =>  12-octet
initialization vector (IV)
Section 10.3. cipher field  =>  ciphertext field
Section 11.1. C_MAX CCM: MUST be at most 2^24+16 octets => ... 2^28 octets
...

2. Mode of operations
In Section 6, keystream generation parts of GCM and CCM are described.
But, both descriptions have some flaws based on NIST specifications
For GCM, pseudocode should be modified as follows:
====================================================================
def GCM_keystream(Plaintext, IV, Encryption_key):    assert len(Plaintext)
<== (2**36 - 32)
    key_stream = ""
    block_counter = 1
    first_key_block = AES_ENC(data = IV || block_counter,

                                               key = Encryption_key)
    while len(key_stream) < len(Plaintext):
        block_counter = block_counter + 1
        key_block = AES_ENC(data = IV || block_counter,
                               key = Encryption_key)
        key_stream = key_stream || key_block
    key_stream = truncate(key_stream, len(Plaintext))
    return (key_stream, first_key_block)
====================================================================
Here, the role of the "first_key_block" (or pre_counter block stated in
NIST SP 800-38C) is the same as that of the "last_key_block"

For CCM, pseudocode should be modified as follows:
====================================================================
def CCM_keystream(Plaintext, IV, Counter_Flag, Encryption_key):    assert
len(Plaintext) <== 2**28
    key_stream = ""
    block_counter = 0
    first_key_block = AES_ENC(data = Counter_block_Flag || IV ||
block_counter,
                                              key = Encryption_key)
    while len(key_stream) < len(Plaintext):
        block_counter = block_counter + 1
        key_block = AES_ENC(data = Counter_Flag || IV || block_counter,
                                            key = Encryption_key)
        key_stream = key_stream || key_block
    key_stream = truncate(key_stream, len(Plaintext))
    return (key_stream, first_key_block)
====================================================================
Tag_Size_Flag is only used as the leading octet of the output value of
InputFormattingFunction.
And there is a separate flag namely Counter_Flag to formatting the counter
block.
Because the pseudocode described in this draft is  related to keystream
generation, the flag should be Counter_Block_Flag.

As noted in GCM, the "first_key_block" is used to generate AEAD
authenticated tag.

3. In Section 5.2, AES-CCM uses a Tag_Size_Flag...:
There are two kinds of flags in CCM. One is in the input formatting
function and the other is in the counter block.
"Tag_Size_Flag" seems to be the former and it is determined by the
existence of associated data, tag size and block counter size.
 Thus the term "Tag_Size_Flag" seems to be unsuitable.
Moreover, the term "Tag_Size_Flag" does not have to be used, since  the
algorithm choice determines the tag size in CCM similarly to GCM,

4. RFC 4771
It seems that there are some differences on implementing RFC 4771 when AEAD
authentication mechanism is used instead of general MAC algorithm.
Though the description of those differences is out of scope of this draft,
it may be possible to make certain of it.

5. In Sections 9.2, 10.2 and 10.3, the length of authentication tags for
SRTP and SRTCP have the same fixed value (32-bit).
In RFC 3711, however, authentication tag length is configurable.

6. In Section 10.2 (Data types in encrypted SRTCP compounded packets), can
the case of empty plaintext field be occurred?

7. Comparing with Figure 4, the only difference of Figure 5 is that the
plaintext field is to be authenticated but not encrypted.
It would be better to unify the description of Sections 10.2 and 10.3 like
Section 3.4 in RFC 3711.

8. In Section 11.2 and 11.3, the tag size of mandatory implementation for
GCM is 8 octets while that for CCM is 16 octets.
 Are there any reasons causing this difference?

9. What about addition of the following cipher suites in 14.1 like DTLS?
- AEAD_AES_128_CCM_8, AEAD_AES_128_CCM_12, AEAD_AES_256_CCM_8,
AEAD_AES_256_CCM_12.

Thanks.

Woo-Hwan Kim