Re: [AVT] Review of draft-ietf-avt-seed-srtp-03

[Eric Rescorla <ekr at networkresonance.com>]

At Fri, 25 Jul 2008 18:17:16 +0900,
Seokung Yoon wrote:
> 
> Dear Eric Rescorla
> 
> I really appreciate your comments.
> Below is my answer.
> If you have any comments about my answer, please let me know.
> 
> Actually, I have no time to modify -03 draft before the AVT meeting.
> So, I will modify it during the IETF 72 meeting period.
> 
> BR,
> Seokung
> 
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Eric
> Rescorla
> Sent: Friday, July 25, 2008 8:55 AM
> To: avt at ietf.org; draft-ietf-avt-seed-srtp at tools.ietf.org
> Subject: [AVT] Review of draft-ietf-avt-seed-srtp-03
> 
> $Id: draft-ietf-avt-seed-srtp-03-rev.txt,v 1.1 2008/07/24 19:38:20 ekr Exp $
> 
> This draft describes the use of the SEED block cipher with SRTP. This
> isn't an inherently bad idea--though it's not particularly compelling
> either. There's no reason to think AES isn't fine, and if AVT wants to
> have cipher options, then there should be real thought given into what
> they are. That said, it's not harmful. Unfortunately, the draft is
> incomplete and probably not implementable as-is.
> 
> >> Actually, I want to add the SEED block cipher in SRTP.

Yes, that's what I mean by "use".


> That means the AES is the default cipher in SRTP and the SEED is the option.
> Also, the SEED is IETF standard (RFC 4269) and ISO/IEC standard. It has a
> strong round function against known attacks.

Yes, I agree it has an RFC #, but as far as I'm aware neither AVT nor
the IETF Security Area has gone through any process to determine what
should be an alternate block cipher to AES, and it's not at all
certain (indeed, I suspect unlikely) would result in selecting SEED.
Again, I'm not saying that it's necessrily a bad idea to standardize
SEED for SRTP (absent the usual arguments about two many options),
but it's not something that it's really important for AVT to do;
it's on the table because you're proposing it.


> OVERALL
> Why are you specifying three separate modes of SEED? I would like to see
> AVT standardize on one or two modes. There's certainly not a lot of value
> in standardizing modes which all have the same general properties,
> as CM + HMAC, CCM, and GCM do. I would select at most two, probably
> AES_CM + HMAC and GCM.
> 
> 
> >> In previous meeting, I got some comments to add CCM and GCM.

Hmm... I think I was the person who raised this issue in PHL, and
what I meant was that you should have a principled answer to
"this is why we're choosing these cipher modes", not just have 
some randomly selected set. 


> Actually, SEED does not have any restriction for modes of operation that are
> used in block ciphers. But, if you want to delete CCM mode, I will reflect
> your comment.

See above.


> How about other options???

What about other options?

> This document badly needs a copy edit. For instance, here's the abstract
> 
> 
> >> I will examine your comments carefully and reflect them.
> 
>    This document describes the use of SEED block cipher algorithm in the 
>    Secure Real-time Transport Protocol (SRTP) for confidentiality to the 
>    RTP traffic and to the control traffic for RTP, the Real-time 
>    Transport Control Protocol (RTCP). 
> 
> I count at least 3 grammatical errors in this sentence
> 
> "of SEED" -> "of the SEED"
> "for confidentiality to the RTP traffic" -> "for providing confidentiality
> for"
> "and to the control traffic" -> "and for the control traffic"

Understand that this was just an example. The document needs a complete
copy edit.

-Ekr
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt