$Id: draft-ietf-sip-media-security-requirements-04-rev.txt,v 1.2 2008/04/05
00:53:27 ekr Exp $
This document seems to me to be in good shape.
I have the following comments about this document. None of these are critical
so I won't cry if they don't get made, and I don't want them to hold
the document up if they're controversy.
S 4.1.
which it is detect-attack, which provides protection against the
"which is"?
before the SDP answer arrives) might make the requirements to become
obsolete, but at the time of writing no progress has been
Not sure I know what this means: "to become obsolete" seems ungramattical
here.
S 4.3.
The entire section on shared key conferencing doesn't lead to any
requirements as far as I can tell. Does it make sense to remove
it from this document?
S 5.1.
R-DISTINCT:
The media security key management protocol MUST be capble of
s/capble/capable/
S 5.3.
R-OTHER-SIGNALING:
A solution SHOULD be able to negotiate keys for SRTP sessions
created via different call signaling protocols (e.g., between
Jabber, SIP, H.323, MGCP).
This is not discussed anywhere in the document. I wonder if it makes
sense to remove it.
Appendix A.
Based on how the SRTP keys are exchanged, each SRTP key exchange
mechanism belongs to one general category:
signaling path: All the keying is carried in the call signaling
Remove one blank line here.
S A.1.12.
It's a little weird to have the discussion of media path keying
properties here before you describe the systems.
S A.1.12.2.
The issues you raise about middleboxes and clipping apply equally
to DTLS-SRTP and ZRTP, no?
S A.1.12.3.
Again, I would think to remove this section.
DTLS-SRTP
Keying: Yes, because with the assumed cipher suite,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, each end indicates its SRTP key.
This statement is not correct. With all conventional TLS modes, neither
side completely controls either key.
S A.1.13.1.
The way you're using "public key cryptography" to mean "PKI" is not
the normal terminology. DH is PKC. I would use PKI to indicate
"certs are needed". So, for instance, SDP-DH and ZRTP definitely use
PKC.
PFS is achieved if the negotiated cipher suite includes an
exponential or discrete-logarithmic key exchange (e.g., Diffie-
Hellman (DH_RSA from [RFC4346]) or Elliptic Curve Diffie-
Hellman [RFC4492]).
I don't know what "exponential or discrete logarithmic key exchange"
means. After all, RSA involves exponentiation. Presumably you mean
"something with ephemeral keys". This currently means discrete log
over integer and elliptic curve fields, but could be RSA in principle.
S A.1.13.3.
It's probably important to indicate that it is desirable to have
the profile be RTP/SAVP when SRTP is used. That's a disadvantage
of media path probing, for instance. I don't think that comes
across clearly here.
S A.3.2.
This document assumes DTLS will use TLS_RSA_WITH_3DES_EDE_CBC_SHA as
its cipher suite, which is the mandatory-to-implement cipher suite in
TLS [RFC4346].
I'm not sure what the relevance of this is. I guess RSA matters, but
since we negotiate a separate protection profile for SRTP, 3DES/SHA
isn't that relevant. Btw, TLS 1.2. will be AES.
Note also that DTLS-SRTP is compatible with RTP before the DTLS
handshake.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
