Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-08.txt

From: Woo-Hwan Kim <[email-masked]>
Date: Tue, 1 Sep 2015 21:25:43 +0900

Hi.

Thank you for your comment.

>>Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-08.txt
>>Magnus Westerlund <[email-masked]> Tue, 02 June 2015
14:32 UTCShow header
>>Hi,
>>
>>I have reviewed the now split document and have some few comments:
>>
>>1. Section 4:
>>
>>   SRTP_ARIA_128_CTR_HMAC_SHA1_80
>>           cipher:                   ARIA_128_CTR
>>           cipher_key_length:        128 bits
>>           cipher_salt_length:       112 bits
>>           maximum_lifetime:         2^31 packets
>>           key derivation function:  ARIA_128_CTR_PRF
>>           auth_function:            HMAC-SHA1
>>           auth_key_length:          160 bits
>>           auth_tag_length:          80 bits
>>
>>What I reacted to is that all of the CTR mode has a maximum_lifetime of
2^31 packets. Is there a reason for this, or could this in fact use the
defaults for SRTP, i.e. RTP 2^48 and RTCP 2^31? I do notice that the
maximum >>length is a bit inconsistent defined between the key-management
functions for other SRTP ciphers. I assume this is an old thing, and not a
result of the split, but I thought it best to bring up. The reason is that
2^31 RTP >>packets are actually not that many, and can force the need for
rekeying.
>>
>>I just want to understand if there is a good reason, or if this is taking
some values, like from DTLS-SRTP for AES, that actually are different from
the ones in SRTP (RFC3711) for that cipher.

Because SRTP_ARIA is defined in the same manner with SRTP_AES,
we just take the parameter values defined in SRTP_AES documents (RFC 3711,
RFC4568, RFC6188, RFC5764, and draft-ietf-avtcore-srtp-aes-gcm).

Especially we refer to RFC 6188 for SDES(SDP Security Description) AES-CTR
crypto suites and to RFC 5764 for DTLS-SRTP protection profiles.
Both references show the default key lifetime as 2^31 packet.
We think that the reason why only '2^31 packet' was given, comes from the
consideration of recommendations for re-keying.

Third paragraph of Section 9.2.(page 38, RFC 3711):
- However, when the session keys for related SRTP and SRTCP streams are
derived from the same master key, the upper bound that has to be considered
is in pratice the minimum of the two quantities.

First paragraph of Section 6.2.1.(page 16, RFC 4568):

- SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes
first. However, it is RECOMMENDED that automated key management allow easy
and efficient rekeying at intervals far smaller than 2^31 packets given
today's media rates or even HDTV media rates.

Because AES_128_CM SDES crypto suites(RFC 4568) and AES_GCM SDES crypto
suites/DTLS-SRTP protection profiles(draft-ietf-avtcore-srtp-aes-gcm)
follow the defaults for SRTP(RTP 2^48 and RTCP 2^31), we will also revise
the maximum_lifetime values for ARIA_CTR transforms as the defaults.

>>2. Section 4:
>>   SRTP_ARIA_256_CTR_HMAC_SHA1_32
>>           cipher:                   ARIA_256_CTR
>>           cipher_key_length:        128 bits
>>
>>I assume this should actually say "256 bits"?

OK, You're right.

>>3. Remove SRTP_AEAD_ARIA_128_GCM_8
>>
>>Based on that AES-GCM with 64 bit tags fails to provide the expected
security, I am of the opinion that the ARIA counter part cipher needs to be
removed.

OK. We will remove SRTP_AEAD_ARIA_128_GCM_8.

Sooner, we will revise the draft.

Sincerely, Woo-Hwan Kim