I agree with the Recommended status on these. Might be good to run the first one by EKR.
On Dec 13, 2010, at 3:09 PM, Worley, Dale R (Dale) wrote: > ====================================================================== > RFC5479, "Requirements and Analysis of Media Security Management Protocols" > Source of RFC: sip (rai) > > Errata ID: 2602 > > Status: Reported > Type: Technical > > Reported By: Fabio Pietrosanti > Date Reported: 2010-11-04 > > Section A.5.2 says: > > SDP Security Descriptions with SIPS > Not applicable; SDP Security Descriptions does not have a long- > term secret. > > It should say: > > SDP Security Descriptions with SIPS > The PFS feature of SDP Security Description with SIPS rely on > TLS and the availability or not of PFS for SRTP calls depends > on the negotiated TLS key negotiation algorithm. > > If the selected TLS key negotiation algorithm of SIPS provide > PFS feature, then the underlying SRTP encryption will support > PFS. For example TLS_DHE_RSA_WITH_AES_256_CBC_SHA provde PFS > feature as described in RFC5246. If the selected TLS key > negotiation algorithm of SIPS does not provide PFS feature, > then the underlying SRTP encryption will not support PFS. > For example TLS_RSA_WITH_AES_256_CBC_SHA does not provide PFS > feature as described in RFC5246. > > > Notes: > > It's not true that SDP Security Descriptions with SIPS have PFS "Not > applicable" because the SDES rely on TLS that is part of the security > scheme. > > Practically if the long terms keys (the x509v3 RSA key of SIPS server) > is compromised, the TLS sessions can be decrypted, the SDES key > extracted and SRTP calls deciphered. > > TLS support key exchange methods that provide PFS trough the use of > Ephemeral Diffie Hellman keys. > > When SIPS use TLS with DHE key negotiation, then SDES acquire PFS > feature because even in case of long-term key compromise (the server > x509v3 RSA key), the short term keys (the SDES keys exchanged) will be > safe. > ---------------------------------------------------------------------- > Recommended status: (correct) Verified (publish) > Should be reviewed by a security expert. > > It seems that the entry for "SDP Security Descriptions with S/MIME" is > also incorrect, as revelation of the private keys of the participants > will render the SDES readable. I think better phrasing of the revised > wording is: > > SDP Security Descriptions with SIPS > PFS if the selected TLS cipher suites for the SIPS hops provide PFS. > > SDP Security Descriptions with S/MIME > No PFS. > > This needs to be reviewed by a security expert. > ====================================================================== > RFC5479, "Requirements and Analysis of Media Security Management Protocols" > Source of RFC: sip (rai) > > Errata ID: 2120 > > Status: Reported > Type: Editorial > > Reported By: Alfred Hoenes > Date Reported: 2010-04-05 > > Section 4.4,3rd para says: > > | A typical case of using media security where two entities are having > a Voice over IP (VoIP) conversation over IP-capable networks. > [...] > > It should say: > > | A typical case of using media security is where two entities are > having a Voice over IP (VoIP) conversation over IP-capable networks. > [...] > > Notes: > > Rationale: missing verb. > ---------------------------------------------------------------------- > Recommended status: (correct) Hold for document update > ====================================================================== > > Dale > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is essentially closed and only used for finishing old business. > Use [email protected] for questions on how to develop a SIP > implementation. > Use [email protected] for new developments on the application of sip. > Use [email protected] for issues related to maintenance of the core SIP > specifications. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications.
