Subject: [AVT] Fwd: draft-ietf-avt-seed-srtp-05 LC comments

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Sep 2008 14:13:03 -0600

Begin forwarded message:

> From: Alfred HÎnes <[email-masked]>
> Date: September 19, 2008 8:52:55 AM MDT (CA)
> To: [email-masked], [email-masked], [email-masked], [email-masked] 
> , [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: draft-ietf-avt-seed-srtp-05 LC comments
>
> Hello,
> after studying the Internet-Draft authored/edited by you,
>                draft-ietf-avt-seed-srtp-05,
> I'd like to submit a few comments, mostly addressing textual
> flaws I found in that memo.
>
> Unfortunately, in this draft I observe the revival of quite a
> couple of issues that already had been discussed and/or resolved
> for previous documents.
> Therefore, and for brevity, I will not re-iterate in great detail
> the rationale for many of the text improvement proposals given below.
>
> The items below are presented in textual order.
> To give more context, sometimes I quote larger blocks of text
> literally and show the replacement proposed using the shorthand
> notation:
>
>   <original draft text>
> ---
>   <modified text>
>
> I use change bars ('|' in column 1) and occasionally
> up/down pointing marker lines ('^^^'/'vvv') to emphasize
> the location of textual issues and/or proposed corrections.
> Modified text has been re-adjusted to match RFC formatting
> rules, where appropriate.  I also try to accomodate published
> RFC-Ed policy on style and punctuation etc. in my proposals.
>
>
> (1)  Section 1
>
> Please fix the language (cf. the updated Abstract):
>
>   This document describes the use of SEED [RFC4009] block cipher
>   algorithm [...]
> ---                                  vvvvv
>   This document describes the use of the SEED [RFC4009] block cipher
>   algorithm [...]
>
>
> (2)  Section 1.1
>
> (2a)  1st paragraph
>
> Please disambiguate and improve:
>
>             ????????
>   SEED is a national industrial association standard [TTASSEED] and is
>   widely used in South Korea for electronic commerce and financial
>   services that are operated on wired and wireless communications.
> ---         vvvvvvvvv        v          v
> |  SEED is a Korean National Industrial Association standard  
> [TTASSEED]
>   and is widely used in South Korea for electronic commerce and
>   financial services that are operated on wired and wireless
>   communications.
>
> (2b)  2nd paragraph, first half
>
>                  [...]  SEED has the 16-round Feistel structure.
> ---                               v
> |                 [...]  SEED has a 16-round Feistel structure.
>
>
> (2c)   2nd paragraph, second half, and 3rd paragraph
>
> The draft says:
>
>   A 128-bit input is divided into two 64-bit blocks, and the right 64-
>   bit block is an input to the round function with a 64-bit subkey  
> that
>   is generated from the key scheduling.
>
>   SEED is robust against known attacks including DC (Differential
>   cryptanalysis), LC (Linear cryptanalysis), and related key attacks.
>   SEED has gone through wide public scrutinizing procedures. It has
>   been evaluated and is considered cryptographically secure by  
> credible
>   organizations such as ISO/IEC JTC 1/SC 27.
>
> These details have been given frequently in the past and are rather
> irrelevant for the purpose of this document.  The citation of RFC 4009
> given above in the text should suffice entirely for this purpose.
>
> Thus, I request to drop this re-iterated 'marketing stuff' from the
> draft.
>
>
> (3)  Section 2
>
> The draft says:
>
>   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.
>
> Many notes:
>
> Unless the [number of] 'rounds' is an explicit parameter of a
> block cipher algorithm, it is not externally visible and does
> not matter at all for the external interface of such building block.
> Furthermore, the 'number of rounds' is a rather scale of very
> local scope;  6 rounds in one algorithm might be considered much
> stronger than, say, 20 rounds in another algorithm. Thus, IMHO
> 'rounds' also does not properly qualify as a "valuable".
>
> In current understanding, the 'mode of operation' is a secondary
> layer above the basic block cipher algorithm, intended for easy
> and schematic plug-in of the primitives into the next higher layer
> modes of operation.  As such, the 'mode of operation' in the
> contemporary literature is *not* considered a characteristic
> of a block cipher primitive.
>
> The last sentence quoted above is rather pointless, as the
> important facts already have been mentioned in Section 1.1.
>
> Consequently, I'll also request dropping of Sections 2.3-2.5.
>
> Regarding the second paragraph, I do not see why we need two
> different sections on the details of SEED.
> Hence, the second paragraph of section 2 should be amalgamated
> with Section 1.1 or dropped.
>
>
> (4)  Section 2.1
>
> The draft says:
>
>   The SEED does not have any restriction for modes of operation that
> |  are used in block ciphers. We define 8 modes of running SEED and an
>                                        ^
>   implementation may choose to operate in a single mode of operation.
>
> In the sequel of the draft, I only see the specification of *three*
> well-known modes of operation to SEED:
>   -  2.1.1 defines SEED-CM
>   -  2.1.2 defines SEED-CCM
>   -  2.1.3 defines SEED-GCM
>
> So please fix up:  s/8/3/ .
>
> Further, as repeated above, the 'mode of operation' is a higher
> concept than the block cipher primitive.
> Thus talking about
>    ... modes of operation ... used *in* block ciphers
> is very confusing.
>
> Finally, the initial article should be dropped.
>
> Also performing some streamlining of text, I suggest to change
> the above snippit to say:
>
> |  SEED does not have any restrictions for modes of operation that are
> |  used with this block cipher.  We define three modes of running SEED
> |  and an implementation may choose to operate in one of them.
>
>
> (5)  Section 2.1.1
>
> The draft says:
>
>   Section 4.1.1 of [RFC3711] defines AES counter mode encryption,  
> which
>   it refers to as AES-CM. SEED counter mode is defined in a similar
> |  manner, and is denoted as SEED_CM respectively. The plaintext  
> inputs
> |  to the block cipher are formed as in AES-CM, and the block cipher
>   outputs are processed as in AES-CM. The only difference in the
> |  processing is that SEED-CM use SEED. Implementations MUST use  
> SEED-CM
>   in conjunction with an authentication function. The pre-defined
>   authentication transform for SRTP is HMAC-SHA1 [RFC 2104]. SEED-CM
>   uses a 112-bit salt as an input, as does AES-CM. The default session
>   authentication key-length SHALL be 160 bits, the default
>   authentication tag length SHALL be 80 bits, and the
>   SRTP_PREFIX_LENGTH SHALL be zero for HMAC-SHA1. For SRTP, smaller
>   values are NOT RECOMMENDED, but MAY be used after careful
> |  consideration of the issues in section 7.5 and 9.5 of [RFC3711].
>
> As far as I can see, "CTR" has been adopted by the community as
> the abbreviation for counter mode, to reduce the danger of confusion
> with CCM, where th 'M' stands for "MAC".
> Therefore, I suggest to denote this mode using SEED as "SEED-CTR".
>
> In any way, all names adopted should be used consistently, not
> switching to underscore or space in place of embedded hyphen(s).
>
> Also introducing some more clraifications and language improvements,
> I propose to change the text of this section as follows:
>
> ---
>   Section 4.1.1 of [RFC3711] defines AES counter mode encryption,  
> which
>   it refers to as AES-CM.  SEED counter mode is defined in a similar
> |  manner, and is denoted as SEED-CM.  The plaintext inputs to the  
> block
>                                 ^^^^
>   cipher are formed as in AES-CM, and the block cipher outputs are
>   processed as in AES-CM.  The only difference in the processing is
>   that SEED-CM uses SEED as the underlying encryption primitive.
>                ^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  Implementations of this specification MUST use SEED-CM in  
> conjunction
>                  ^^^^^^^^^^^^^^^^^^^^^^^
>   with an authentication function.  The pre-defined authentication
>   transform for SRTP is HMAC-SHA1 [RFC 2104].  SEED-CM uses a 112-bit
>   salt as an input, as does AES-CM.  The default session  
> authentication
>   key length SHALL be 160 bits, the default authentication tag length
>   SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero for
>   HMAC-SHA1.  For SRTP, smaller values are NOT RECOMMENDED, but MAY be
> |  used after careful consideration of the issues discussed in section
>   7.5 and 9.5 of [RFC3711].
>                                                 ^^^^^^^^^^^
>
> ... or with the proposed name change  SEED-CM --> SEED-CTR :
>
>   Section 4.1.1 of [RFC3711] defines AES counter mode encryption,  
> which
>   it refers to as AES-CM.  SEED counter mode is defined in a similar
> |  manner, and is denoted as SEED-CTR.  The plaintext inputs to the
>                                 ^^^^^
>   block cipher are formed as in AES-CM, and the block cipher outputs
>   are processed as in AES-CM.  The only difference in the processing  
> is
> |  that SEED-CTR uses SEED as the underlying encryption primitive.
>             ^^^ ^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  Implementations of this specification MUST use SEED-CTR in
>                  ^^^^^^^^^^^^^^^^^^^^^^^              ^^^
>   conjunction with an authentication function.  The pre-defined
> |  authentication transform for SRTP is HMAC-SHA1 [RFC 2104].  SEED- 
> CTR
>                                                                    ^^^
>   uses a 112-bit salt as an input, as does AES-CM.  The default  
> session
>   authentication key length SHALL be 160 bits, the default
>   authentication tag length SHALL be 80 bits, and the
>   SRTP_PREFIX_LENGTH SHALL be zero for HMAC-SHA1.  For SRTP, smaller
>   values are NOT RECOMMENDED, but MAY be used after careful
> |  consideration of the issues discussed in section 7.5 and 9.5 of
>   [RFC3711].
>                              ^^^^^^^^^^^
>
> (6)  Section 2.1.2
>
> (6a)
> For consistency, please introduce the name and change:
>
>   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].  
> In
> |  this specification, CCM is used with the SEED block cipher.
>
> |  SEED CCM has two parameters:
> ---    ^
>   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].  
> In
> |  this specification, CCM is used with the SEED block cipher is  
> denoted
>   vvvvvvvvvvv                                                
> ^^^^^^^^^^^
> |  as SEED-CCM.
>
> |  SEED-CCM has two parameters:
>       ^
>
> (6b)
> In the explanation of 'M' please change:
>
>       ... two application environment ...
> ---                                   v
>       ... two application environments ...
>
> (6c)
> In the explanation of 'L' please insert the missing article,
> an clarify:
>
>     L   L indicates the size of the length field in octets. In SRTP,
> |        the size of length field is 16 bits. Implementations MUST
>                    ^
>         support an L value of 2 octets.
> ---
>     L   L indicates the size of the length field in octets. In SRTP,
> |        the size of the length field is 16 bits, i.e., L is 2.
>                    ^^^^^                       ^^^^^^^^^^^^^^
>         Implementations MUST support an L value of 2 octets.
>
> [ The last sentence seems to be rather tautological, after the first
>  one.  So why not simply drop it ? ]
>
> (6d)
> In the explanation of 'Key' please insert the missing article:
>
>         A single key is used to calculate the authentication tag using
>         CBC-MAC and to perform payload encryption using counter mode.
>         SEED only supports key size of 128 bits. Implementation MUST
>         support this key size.
> ---
>         A single key is used to calculate the authentication tag using
>         CBC-MAC and to perform payload encryption using counter mode.
>         SEED only supports a key size of 128 bits. Implementation MUST
>         support this key size.
>
> [ The last sentence seems to be rather tautological, after the first
>  one.  So why not simply drop it ? ]
>
> (6e)
> In the explanation of 'Nonce', I suggest the following clarifications:
>
>         The size of the nonce depends on the value selected for the
>         parameter L. L equals 2 and that nonce size equals 13.
>         Implementations MUST support a nonce of 13 octets. SEED-CCM
>         nonce is defined as the most significant bits of the
>         initialization vector (IV) defined in section 4.1.1 of
>         [RFC3711].
> ---
>         The size of the nonce depends on the value selected for the
> |        parameter L.  With SRTP, L equals 2 and hence the nonce size
>                       ^^^^^^^^^^^               ^^^^^^^^^^
>         equals 13 octets.  Implementations MUST support a nonce of 13
> |        octets.  The SEED-CCM nonce is defined as the 104 most
>                  ^^^^                                ^^^^^
>         significant bits of the initialization vector (IV) defined in
>         section 4.1.1 of [RFC3711].
>
> [ Again, the second sentence seems to be rather tautological, after
>  the first one.  So why not simply drop it ? ]
>
>
> (7)  Section 2.1.3
>
> (7a)  1st paragraph
>
> Similarly as above, I suggest to change:
>
>   GCM is a block cipher mode of operation providing both
> |  confidentiality and data origin authentication [GCM].GCM is used  
> with
> |  the SEED block cipher.
>                        ^                              ^   ^^^^
> to either:
>
>   GCM is a block cipher mode of operation providing both
> |  confidentiality and data origin authentication [GCM].  GCM used  
> with
> |  the SEED block cipher is denoted as SEED-GCM.
>                        ^^^^^^^^^^^^^^^^^^^^^^^        ^^^   ^
> or:
>
>   GCM is a block cipher mode of operation providing both
> |  confidentiality and data origin authentication [GCM].  SEED-GCM  
> uses
>   GCM with the SEED block cipher.
>                                                       ^^^^^^^^^^^^^^^^
>
> (7b)  last paragraph -- clarifications, and a missing article
>
> |  SEED-GCM defines an IV. The size of the IV is 12 octets.
> |  Implementations MUST support this octet size. SEED-GCM IV is  
> defined
> |  as the most significant bits of the initialization vector (IV)
>   defined in section 4.1.1 of [RFC3711].
> ---
> |  SEED-GCM makes use of an IV.  The size of the IV is 12 octets.
>            ^^^^^^^^^^^^
> |  Implementations MUST support this IV size.  The SEED-GCM IV is
>                                     ^^       ^^^^^
> |  defined as the most significant 96 bits of the initialization  
> vector
>                                  ^^^^
>   (IV) defined in section 4.1.1 of [RFC3711].
>
>
> (8)  Sections 2.2 - 2.4
>
> The content of these setcions is a mere re-statement of parts of
> sections 1.1 and 2, and the referenced RFC 4009 [SEED].
> It is by no means specific to this document.
>
> Hence, I strongly suggest to drop these three sections.
>
> Doing so will allow to simplify the section numbering,
> incorporating the text in 2.1 into section 2 will allow
> to renumber sections  2.1.{1,2,3}  to  2.{1,2,3} .
>
>
> (9)  Section 3
>
> The security considerations should be amended, pointing to
> the referenced basic documents.
> For instance, add to the end of the existing text:
>
>   See [CCM] and [GCM] for security considerations regarding the CCM
>   and GCM Modes of Operation, respectively.  In the context of SRTP,
>   the procedures in [RFC3711] ensure the critical property of non- 
> reuse
>   of counter values.
>
>
> Best regards,
>  Alfred HÎnes.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- 
> Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax:  
> -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>

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

---

From: 윤석웅 <[email-masked]>
Date: Mon, 22 Sep 2008 11:43:48 +0900 (KST)

WINiPMail Mail

Dear Alfred Hoenes.

Thank you for your comments.

All comments will be basically accepted and relected in next draft.

BR,

Seokung

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

From: Cullen Jennings <[email-masked]>

Sent: Sat Sep 20 05:13:03 KST 2008

To: IETF AVT WG <[email-masked]>

Subject: [AVT] Fwd: draft-ietf-avt-seed-srtp-05 LC comments

Begin forwarded message:

> From: Alfred H?nes <[email-masked]>

> Alfred H?nes.

[email-masked]