At Wed, 9 Apr 2008 18:10:05 -0700, Dan Wing wrote: > > 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. > > Changed to: > > Preventing the arrival of early media (i.e., media that > arrives at the SDP offerer before the SDP answer arrives) > might obsolete the R-AVOID-CLIPPING requirement, but at the > time of writing such early media exists in many normal call > scenarios.
Looks good. > > 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? > > Right. It seems useful to leave it in, as mentioned at the beginning > of the section: > > The consensus on the RTPSEC mailing list was to concentrate on > unicast, point-to-point sessions. Thus, there are no requirements > related to shared key conferencing. This section is retained for > informational purposes. > > if others agree it should be removed, I can remove it. I've got no real problem with leaving it in, I just wanted to note it. > > 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. > > I know that my employer's products interwork between SIP and MGCP (and > our proprietary SCCP) with SRTP today -- all using Security Descriptions. > > I know we have a need to meet this requirement with anything that > replaces our Security Descriptions implementations. I expect others > do, too. > > Would adding motivating text (in a new subsection 4.xxx) be useful? I > had assumed the need was self-evident. As a matter of form, I think it would be good to have a section with motivating text. > > S A.1.12.2. > > The issues you raise about middleboxes and clipping apply equally > > to DTLS-SRTP and ZRTP, no? > > ZRTP allows RTP to flow while the ZRTP exchange is happening, so ZRTP > should incur no clipping. > > 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. > > Ok. Changed from: > > Using public key cryptography for confidentiality and authentication > can introduce requirements for two types of systems: (1) a system to > distribute public keys (often in the form of certificates), and (2) a > system for validating certificates. > > to: > > Requiring certificates for confidentiality and authentication > can introduce requirements for two types of systems: (1) a system to > distribute certificates, and (2) a system for validating certificates. Looks good. > > 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. > > Thanks. I don't know where that text came from (it isn't my wording > but it was in my original -00). Changed to: > > DTLS-SRTP > PFS is provided if the negotiated cipher suite uses ephemeral > keys (e.g., Diffie-Hellman (DH_RSA from [RFC4346]) or Elliptic > Curve Diffie-Hellman [RFC4492]). s/DH_RSA/DHE_RSA/. DH_RSA means static keys. > > 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. > > There is a disadvantage with RTP/SAVP as the profile, as well, mentioned at > the beginning of that section -- just prior to the list of candidate > techniques. > > This section is titled Best Effort Encryption, and RTP/SAVP is not a candidate > technique to provide best effort encryption -- RTP/SAVP causes a call to fail > to complete if any of the remote forks or targets (during retargeting) rejects > the call because they don't understand that profile. This is discussed at the > beginning of that section, in order to justify why we need best effort > encryption -- so that we can deploy SRTP without a priori knowledge of the > called party's deployment of RTP/SAVP-capable endpoints at that particular > moment. So, maybe I just misunderstood the situation: I had thought that with the new media cap stuff one would offer both RTP/SAVP and RTP/AVP, so you would get best effort. Am I confused? > > 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. > > Thanks, changed to: > > This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as > its cipher suite, which is the mandatory-to-implement cipher suite in > TLS [I-D.ietf-tls-rfc4346-bis]. > > > Note also that DTLS-SRTP is compatible with RTP before the DTLS > > handshake. > > Only if the RTP profile is RTP/AVP; if the profile is RTP/SAVP, one expects > only SRTP. Is there text that needs to change to note that in the > requirements doc? Not sure. See my comment above about RTP/SAVP. -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
