Re: [Gen-art] Request for comments regarding SEED-SRTP
윤석웅 <seokung@kisa.or.kr> Fri, 17 April 2009 12:16 UTC
Return-Path: <seokung@kisa.or.kr>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5581B3A6B09 for <gen-art@core3.amsl.com>; Fri, 17 Apr 2009 05:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.69
X-Spam-Level:
X-Spam-Status: No, score=-93.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_ASCII0=1.5, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITpTrpCII66O for <gen-art@core3.amsl.com>; Fri, 17 Apr 2009 05:16:09 -0700 (PDT)
Received: from spam.kisa.or.kr (sniper.kisa.or.kr [211.252.150.22]) by core3.amsl.com (Postfix) with ESMTP id 5F8163A6F87 for <gen-art@ietf.org>; Fri, 17 Apr 2009 05:16:08 -0700 (PDT)
Received: (snipe 11164 invoked by alias); 17 Apr 2009 21:16:30 +0900
Received: from unknown (HELO ekp) (211.252.150.33) by 211.252.150.22 with SMTP; 17 Apr 2009 21:16:30 +0900
Received: from ekp (ekp [211.252.150.33]) by webmail.kisa.or.kr (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0KI8005QRVGK78@webmail.kisa.or.kr> for gen-art@ietf.org; Fri, 17 Apr 2009 21:17:08 +0900 (KST)
Date: Fri, 17 Apr 2009 21:17:08 +0900
From: 윤석웅 <seokung@kisa.or.kr>
In-reply-to: <49E7B0DB.2030005@folly.org.uk>
To: elwynd@folly.org.uk
Message-id: <18855567.1239970628118.JavaMail.jeus@ekp>
MIME-version: 1.0
X-Mailer: WINipMail2.5.1
Content-type: multipart/mixed; boundary="----=_Part_39_18504142.1239970628009"
X-Priority: 3
X-UserInfo: 윤석웅/IT기반보호단/선임/seokung@kisa.or.kr
X-UserUID: A0600
X-Identifier: cbda-120b40241a8-aacf-ekp
X-Mailman-Approved-At: Fri, 17 Apr 2009 06:18:09 -0700
Cc: fluffy@cisco.com, General Area Review Team <gen-art@ietf.org>, David McGrew <mcgrew@cisco.com>, avt-chairs@tools.ietf.org
Subject: Re: [Gen-art] Request for comments regarding SEED-SRTP
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2009 12:16:10 -0000
Dear Elwyn Davies
Thanks for your comments.
Here is my answer (<<) and send the revised draft.
Please check it again to finish this process, ^^
BR,
Seokung
To: David McGrew <mcgrew@cisco.com>
Cc: 윤석웅 <seokung@kisa.or.kr>, fluffy@cisco.com, avt-chairs@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
Subject: Re: Request for comments regarding SEED-SRTP
Hi, Seokung.
For section 2.2, I *still* think it would be good to be totally explicit
as I said: Something like:
- At the sender: perform step 7 before step 5.
- At the receiver: perform the second half of step 5 (perform
verification) after step 6.
This means that authentication is performed on the cleartext rather than
the ciphertext.
>> I reflected.
Presumably this applies equally to SRTCP? You should say so if it is true.
>> I reflected.
It occurs to me (belatedly) that this reordering apparently increases
the processing that has to be done on packets before the authentication
is verified, providing a greater impact for a DoS attack that modifies
the encrypted payload. I think this should be noted in the security
considerations (assuming I am correct). Is this a significant problem
given encryption is mandatory on some packets?
>> I already mentioned the security consideration to use GCM and CCM like : See [RFC3610] and [GCM] for security considerations regarding the CCM
and GCM Modes of Operation, respectively.
The other problem was fixed.
Regards,
Elwyn
David McGrew wrote:
> Hi Seokung
>
> It looks like almost all of my comments were addressed. I did notice a
> couple things, though. The first is important, the second is very minor.
>
>>
>> There is no definition of how CCM and GCM are to be used to protect
>> RTCP. It would not be possible to use this specification to protect
>> RTCP packets with those algorithms.
>
> The new draft says "In case of SRTCP, the Authentication Portion
> described in Fig.2 of [RFC3711] is treated as AAD." Is that true even
> if the E bit is equal zero? I suspect that what you want here is to
> have a definition such that, when E=0, the AAD format for SRTCP is
> specified differently. (Either that or a restriction to not use E=0.)
>
>>
>>
>> In Section 2, I don't understand the meaning of "and valuables" and I
>> suggest just removing the phrase.
>>
>
> I notice that the word is still there. Perhaps "variables" was the
> intended word?
>
> Apologies for the lag in my getting this review done.
>
> Best regards,
>
> David
>
>
> On Apr 2, 2009, at 6:14 AM, 윤석웅 wrote:
>
>> Dear David Mcgrew and Elwyn Davies.
>>
>>
>> Thanks for your lots of comments during AD last call.
>>
>> I really appreciated it.
>>
>>
>> Here is the revised draft to reflect whole your comments.
>>
>> Please check if thers is any problem or deficiency.
>>
>>
>> If you are OK, I will submit it to proceed next step.
>>
>>
>> BR,
>>
>> Seokung
>>
>> <draft-ietf-avt-seed-srtp-10(alpha).txt>
>