[AVT] comments on draft-ietf-avt-seed-srtp-09.txt

[David McGrew <[e-mail]>]

Hello,

I have some concerns about draft-ietf-avt-seed-srtp-09; there are  
several issues that deserve to be addressed.  This message is a  
response to the last call.

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.

Section 2.2 defines the "Additional Authentication Data (AAD)" as "the  
header of the RTP packet", which does not include the RTP Contributing  
Source (CSRC) identifiers and optional RTP header extension.  Since  
these fields are not included in SRTP encryption, their omission from  
the AAD input means that they are left unauthenticated.  Presumably  
this omission was inadvertent.

Section 2.1 defines the CTR counter format to match RFC 3711, while  
Section 3 defines a different counter format for CCM and GCM. The  
latter format does not have any "salt" in it, unlike the former  
format.  This omission seems like a bad idea, since there is  
essentially zero cost for including the salt in the counter, and the  
salt provides quantifiable security benefits.  It protects against key  
collision attacks and time-memory tradeoff attacks (see http://citeseer.ist.psu.edu/old/mcgrew00attacks.html 
  for example) and also makes integral cryptanalysis (the "SQUARE"  
attack) considerably more difficult.  This last point is important for  
CCM and GCM since counter mode provides exactly the inputs that are  
needed in order to prosecute this type of attack.  SEED was designed  
not long after the initial description of integral cryptanalysis, but  
before that attack was fully developed.  The prudent thing to do would  
be to use a GCM and CCM counter format that that includes the salt  
value.

Below I have some editorial comments.

In Section 2, I don't understand the meaning of "and valuables" and I  
suggest just removing the phrase.

Section 2.1 says:

    Implementations of this specification MUST use SEED-CTR in
    conjunction with an authentication function.

I think that what is actually meant is:

    When SEED-CTR is used, it must be used only in
    conjunction with an authentication function.

Section 2.2 says:

    This does not comply with the SRTP packet processing
    defined in section 3.3 of [RFC3711].

I think that what is meant is that the specification is meant to  
supersede RFC 3711, or one section of it.  This needs to be clarified.

Section 2.2 says that "the number of octets in the nonce SHOULD be  
12".  SHOULD needs to be changed to MUST in order to ensure  
interoperability.

Section 4 says "The SEED-CTR PRF is defined in a similar manner."    
Presumably it means " ... defined in a similar manner, but with each  
invocation of AES replaced with an invocation of SEED."

In Section 5, I suggest clarifying that "mandatory to implement" means  
conformance to the specification, and that Table 1 does not supersede  
RFC 3711.

Lastly, I suggest that the status of the SEED algorithm within the  
Republic of Korea be clarified.  RFC 4009 says that it is "a national  
standard encryption algorithm", which suggests a special governmental  
status, while RFC 4269 does not say that, and instead says that it  
"has been adopted by most of the security systems", and draft-ietf-avt- 
seed-srtp says that it is "a Korean National Industrial Association  
standard and is widely used in South Korea for electronic commerce and  
financial services that are operated on wired and wireless  
communications."    Does SEED have a particular standing with the  
government of the Republic of Korea, as RFC 4009 suggests?   If so, it  
would be good to state that.

Best regards,

David