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

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Jul 2008 16:55:27 -0700

$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.

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.

There are way too many possible parameter settings and it's not at
all clear how they get established. You should describe a small number
of profiles and explain how key management establishes them.

This document badly needs a copy edit. For instance, here's the abstract

   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"

The rest of the document has numerous editorial issues.

DETAILED
S 1.1.
   The usage of SEED has been covered the security service applications 
   such as e-Commerce, e-mail, dedicated receiver with Broadcasting, 
   financial service, data storage, electronic toll collection, VPN, 
   Digital Right Management, etc. 

What does this mean?

S 2.
   All symmetric block cipher algorithms share common characteristics 
   and valuables, including mode, key size, weak keys, block size, and 
   rounds. The following sections contain description of the relevant 
   characteristics of SEED. 

I'm not sure what this means. Perhaps you're trying to say that 
block ciphers can be characterized by these parameters? What's
the take-home?

S 2.1.1.
Which authentication tag lengths are possible?

S 2.1.2.
Why would you want to have 7 possible authentication tag lengths?
3711 really only uses two now. 

It's not entirely clear to me how to map AEAD ciphers onto SRTP.
As I read the CCM spec, there is only a single output value (c).
Are you going to treat this as the ciphertext with no explicit
authentication tag? Are you going to break them up? This needs
to be defined. What's probably best here is a mapping of RFC 5116
onto SRTP.

I'm not an RTP expert, but isn't RTP carried over UDP, which has
a 2 byte length field? Why do you need to be able to support
super-long lengths.

What do you mean "MUST support" a nonce of 11 octets. Wouldn't
it be better to simply nail down this value?

What's S 4.1.1? Of what document?

S 2.1.3.
This is the same as AES-GCM except with SEED? Just say so.

[Again] What's S 4.1.1? Of what document?

S 2.2.
What do you mean "supports 128-bit key". are tehre multiple
possibilities or is it a fixed-length key.

-Ekr

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Seokung Yoon <[email-masked]>
Date: Fri, 25 Jul 2008 18:17:16 +0900

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: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rescorla
Sent: Friday, July 25, 2008 8:55 AM
To: [email-masked]; [email-masked]
Subject: [AVT] Review of draft-ietf-avt-seed-srtp-03

>> Actually, I want to add the SEED block cipher in SRTP.
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.

OVERALL

>> In previous meeting, I got some comments to add CCM and GCM.
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.
How about other options???

>> I will reflect it.

>> I will examine your comments carefully and reflect them.

"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"

DETAILED
S 1.1.

What does this mean?

S 2.

S 2.1.1.

S 2.1.2.

S 2.1.3.

S 2.2.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 08:33:38 -0700

At Fri, 25 Jul 2008 18:17:16 +0900,
> >> Actually, I want to add the SEED block cipher in SRTP.

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

> 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.

> >> 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. 

> used in block ciphers. But, if you want to delete CCM mode, I will reflect

See above.

> How about other options???

What about other options?

> "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

---

From: 윤석웅 <[email-masked]>
Date: Mon, 28 Jul 2008 22:26:17 +0900 (KST)

WINiPMail Mail

Dear Eric Rescorla

Here is my answer about some issues.

BR,

Seokung

----- 메일의 원문 -----

From: Eric Rescorla <[email-masked]>

Sent: Sat Jul 26 00:33:38 KST 2008

To: Seokung Yoon <[email-masked]>

Cc: 'Eric Rescorla' <[email-masked]>, [email-masked], [email-masked]

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

Seokung Yoon wrote:

>> Nowdays administration ministry in korea spreads VoIP services
in the government buildings.

But, as you know VoIP has some vulnerabilities such as eavesdropping..etc.

So, we establish encryption standard in korea to protect signal and
media traffic.

In korea, AES and SEED should be supported in SRTP because the SEED
is a national standard.

That's why I proposed the initial draft and it should be reviewed in AVT.

Hopefully, it would deserve to be standardized.

>> In the first draft of SEED-SRTP, I just defined only CM+HMAC because

I do not want to make a big changes of SRTP.

So I introduced the SEED and defined the crypto suites with SEED CM.

But, SEED does not have any restriction for modes of operation that are

used in block ciphers such as CM, CCM, GCM.. whatever..

So I think I define three modes of SEED-SRTP.

I absolutely agree with your opinion about insufficiency.

I really appreciate your comments and want to get more comments.

Definitely, I will copyedit the document.

See above.

copy edit.

-Ekr