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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf