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

Woo-Hwan Kim <> Tue, 01 September 2015 12:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4A741B5881 for <>; Tue, 1 Sep 2015 05:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ugtSgNx1XHIJ for <>; Tue, 1 Sep 2015 05:25:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D604A1B44A9 for <>; Tue, 1 Sep 2015 05:25:44 -0700 (PDT)
Received: by vkbf67 with SMTP id f67so49942356vkb.0 for <>; Tue, 01 Sep 2015 05:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=cdOLCTk9Xrr4P7l6AVnv3VF1rKAg1PGz02Ac5TJ43L8=; b=UBdBUsWmHGvvImKmDSdS9b0fD9SKVgwLebIQ7SkLkMjyRnJ1ONfBLMH1AXeEu5sTgY iPbbeAbIRCBTkkI8qe6fIUbdh5fiD7BzSOT+OUFSr0dExOwyr0qkBJDlbtezHrZ1GPyk Ig3FYppXAJhopY2okbE0lQwRvBZBuqPt0qsIBAvlau7yNEZXgmMlFlzrQfWXr5Ub6RS8 zrJ8WUVDLjlB5erp4K9sc5njjQveXXgNMJM5/bp08tzPhP3nqnGFWxmneXret0a8VY0p iZ3PA3xwPSPS8vzE740cEXPCotoStWFxEzyNzWqSj+nPWh7zzpfIyxAlc/j7+Ypu2HYc SaHw==
MIME-Version: 1.0
X-Received: by with SMTP id m6mr28005599vdi.80.1441110344006; Tue, 01 Sep 2015 05:25:44 -0700 (PDT)
Received: by with HTTP; Tue, 1 Sep 2015 05:25:43 -0700 (PDT)
Date: Tue, 01 Sep 2015 21:25:43 +0900
X-Google-Sender-Auth: C9IswwqIHQ2KuoOhYuzhJ3-Us7U
Message-ID: <>
From: Woo-Hwan Kim <>
To:, Magnus Westerlund <>
Content-Type: multipart/alternative; boundary="bcaec517c4b223031b051eaea61b"
Archived-At: <>
Cc: Je Hong Park <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-08.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Sep 2015 12:25:48 -0000


Thank you for your comment.

>>Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-08.txt
>>Magnus Westerlund <> Tue, 02 June 2015
14:32 UTCShow header
>>I have reviewed the now split document and have some few comments:
>>1. Section 4:
>>           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
>>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:
>>           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

OK. We will remove SRTP_AEAD_ARIA_128_GCM_8.

Sooner, we will revise the draft.

Sincerely, Woo-Hwan Kim