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

[Eric Rescorla <ekr at networkresonance.com>]

$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
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt