Subject: [AVTCORE] Re: Comments on draft-ietf-avtcore-aria-srtp-01

From: Woo-Hwan Kim <[email-masked]>
Date: Thu, 27 Jun 2013 14:13:50 +0900

We'll add some comments regarding the risk of short tags in the security
considerations of new version(-03)
and post a mail about AES-CCM ciphersuites issues.

Thanks.

Best Regards, Woo-Hwan Kim

> Hi,
>
> Please see my replies inline.
>
>
> On 2013-06-04 08:35, Woo-Hwan Kim wrote:
>> First of all, we appreciate your helpful comment on the draft.
>>
>>>>2) Section 2.1 and 4:
>>>>
>>>>What are the security implications of using a 256 bit key length for the
>>>>crypto but have as weak integrity protection as SAH1 32 bits? I think
>>>>you need to discuss the implications of this, it doesn't appear to be
>>>>particular balanced.
>>
>> We think that the key length and tag length should be treated separately.
>> Though the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good,
>> the statement of Section 7.5 in RFC 3711 still seems to be valid for
192/256
>> bit key block cipher.
>> From another point of view, even when the tag length is short,
>> large key length provides more security against key recovery attacks.
>> So we would like to define ARIA ciphersuites corresponding to AES
>> ciphersuites
>> such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose
a
>> proper ciphersuite depending on environments.
>
> Okay, I don't see any significant issue with that, but please be
> explicit in the considerations that this combination is quite loop sided
> from a security perspective.
>
>>
>>>>3) Section 2.2:
>>>>
>>>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>>   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
>>>>   with SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>>
>>>>Looking in AES-GCM it appears to define a generic AEAD procedures for
>>>>SRTP cipher suits. Can you please be more explicit and clear on how you
>>>>use that generic procedure?
>>>>
>>>>
>>>>4) Section 2.1, 2.2:
>>>>
>>>>These procedures are define by reference to existing algorithms like
>>>>these sentences:
>>>>
>>>>    ARIA counter modes are
>>>>   defined in a similar manner, and are denoted by ARIA_128_CTR,
>>>>   ARIA_192_CTR and ARIA_256_CTR respectively, according to the key
>>>>   lengths.  The plaintext inputs to the block cipher are formed as in
>>>>   AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs
>>>>   are processed as in AES-CTR.
>>>>
>>>>   The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>>   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
>>>>   with SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>>
>>>>I think using words as "similar" and not being very explicit about what
>>>>procedures from the other specification that applies here provide some
>>>>risk for misunderstanding. I hope you can be more explicit and clear on
>>>>which procedures and usage are applicable.
>>
>> The only difference between ARIA ciphersuites and AES ciphersuites is
>> whether to invoke ARIA or AES. There is no difference in modes of
>> operation itself.
>> Thus we think it is not necessary to define AEAD procedures and other
>> modes of
>> operations more explicitly in the draft if there are proper references.
>>
>> If the word "similar" is inappropriate, we'll replace it by the word
>> "same".
>> The below sentences can be added.
>>
>> - ARIA counter modes are defined in the same manner except that each
>> invocation of
>> AES is replaced by that of ARIA.
>> - The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as
>> that of AES-CCM and AES-GCM except that each invocation of AES is
replaced
>> by ARIA.
>
> Correct, I agree with reference procedures when they exist. But you need
> to be explicit about this. Same is better, but I haven't judged if that
> makes it obvious how you apply ARIA instead of AES.
>
>>
>> We are following the AES-SRTP documents including
>> draft-ietf-avtcore-srtp-aes-gcm.
>> Section 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is
>> used for CCM and
>> it is written that the tag size for GCM is determined by the algorithm
>> choice.
>> But the tag size for CCM also can be determined by the algorithm choice
and
>> it is better to define CCM ciphersuites for each tag size. We submitted
>> such opinion,
>> but not accepted yet.
>
> Okay, if that discussion is from the AES-GCM last call, I think you need
> to re-raise this on the list as a focused email on that issue. I don't
> seem to be able to find any reply to those comments. So please remind
> the authors about this issue and lets see if we can come to a conclusion
> on it.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>