[AVTCORE] Re: Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03

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

Hi.

Here are some comments on draft-ietf-avtcore-srtp-aes-gcm-03


1. Typos

Sec. 5.3
- Validation Error flag raised =>  Validity_Flag is to be FALSE

Sec. 6
- the plaintext to form cipher => the plaintext to form ciphertext
- this apllication => this application
- A (first_key_block, keystream) pair => A (first_key_block, key_stream)
pair
- These keystream generation processes allows for => These keystream
generation processes allow for
- up to (2^24)-16 octets for AES-CCM and => up to (2^28)-16 octets for
AES-CCM and

Sec. 7
- AEAD_AEC => AEAD_AES

Sec. 8.1
- the older authentication methods redundant => the older authentication
mechanisms redundant
- Some applications use the SRTP/SRTCP Authentication Tag as => Some
applications use the SRTP/SRTCP authentication tag field as

Sec. 8.2
- Neither AES-GCM not AES-CCM => Neither AES-GCM nor AES-CCM
- RECOMENDED => RECOMMENDED

Sec. 9.1
- used by both AES-GCM and AES-CCM SRTP is => used by both AES-GCM and
AES-CCM in SRTP is
- and the two octet sequence number SEQ. => and the 2-octet sequence number
SEQ.

Sec. 9.2 & 10.2
- AEAD cipher, ~containing the cipher, the resulting cipher => AEAD
ciphertext, ~containing the ciphertext, the resulting ciphertext

Sec. 9.2, 10.2 & 10.3 (similar meaning, different writing)
- The data fields within the SRTP packets are broken into Associated Data,
Plaintext and Raw Data as follows (see figure 2):
- the SRTCP packet is broken into plaintext, associated data, and raw
(untouched) data as listed below (see figure 4):
- the SRTCP compound packet is broken into plaintext, associated data, and
raw (untouched) data as follows (see figure 5):

Sec. 10.3
- returns a cipher field which ~, This cipher ~, the Encryption flag => a
ciphertext which ~, This ciphertext ~, the encryption flag

Sec. 11.1
- GCM: MUST be at most 2^36-16 octets CCM: MUST be at most 2^24+16 octets
=> GCM: MUST be at most 2^36-32 octets CCM: MUST be at most 2^28-16 octets

Sec. 11.2 & 11.3
- Any implementation of AES-GCM(AES-CCM) SRTP SHOULD ~ => Any
implementation of AES-GCM(AES-CCM) in SRTP SHOULD ~

Sec. 11.3
- in counter node encryptionn, AES-CCM authentications also useus => ~ in
counter mode encryption, AES-CCM authentications also uses ~

Sec. 12
- AEAD_AES_128(256)_CCM(GCM) algorithms => AEAD_AES_128(256)_CCM(GCM)

Sec. 13.1
- after each block key has => after each encryption key has


2. Editing
Sec. 1 3rd and 4th paragraphs

- In 3rd paragraph, 2nd sentence 'Two families of ~ based upon AES.' is
repeated in 4th paragraph.
So it may be better to remove this sentence, and to modify the last
sentence as follows:
'This specification uses GCM and CCM with AES, which we call AES-GCM and
AES-CCM respectively)'

Sec. 8.1 1st and 2nd sentences

When an AEAD algorithm is used for SRTP/SRTCP, the AEAD message
authentication mechanism MUST be the primary message authentication
mechanism.


3. Length vs Size

It may be good to unify the words 'length' and 'size'


4. CCM authentication tag length

Though the CCM specification adapted by NIST and IETF uses the tag length
to format the message,
basically there is no difference between CCM and GCM to deal with
authentication tag length.
As GCM, CCMs with different tag length (ex. CCM_8, CCM_12) should be
considered separately.
AEAD Parameters managed by IANA also show it.

In addition, it is not necessary to consider the capability of handling
variable-length authentication tags
because this draft restricts the length of authenticated tag to be 8, 12,
or 16.
And tag length should be shared by key manage process based on SDES, DTLS
or MIKEY.
Though MIKEY explicitly supports authentication tag length parameter as
specified in Section 14.3,
SDES and DTLS do not.
Instead, the choice of cipher suite (or protection profile) implies the
authentication tag length directly.
So I think that cipher suites for SDES should be corresponded to protection
profiles for DTLS,
and that is the reason why I recommend to add cipher suites of CCM with
authentication tag length 8 and 12.

Because the authentication tag length is shared during key and parameters
negotiation,
I think that Encrypt/Decrypt mode described in Section 5.2 does not need to
use the term 'Tag_Size_Flag' explicitly.
The above also holds for the Decrypt Mode in 5.2.2.


Thanks.

Best Regards,

Woo-Hwan Kim

> Date: Tue, 27 Nov 2012 15:20:46 +0100
> From: Magnus Westerlund <[e-mail]>
> To: IETF AVTCore WG <[e-mail]>
> Subject: [AVTCORE] Working group last call on
> draft-ietf-avtcore-srtp-aes-gcm-03
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> WG,
>
> This announces the WG last call on AES-GCM and AES-CCM Authenticated
> Encryption in Secure RTP (SRTP)
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/
>
> Please provide any comments no later than the 12th of December. Also
> comments of the nature of "I have read it and have no comments and think
> it should be published" are highly valuable.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> F?r?gatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------