Document: draft-ietf-sip-dtls-srtp-framework-05.txt Reviewer: Suresh Krishnan Review Date: 5-November-2008 IETF LC End Date: 31-October-2008 IESG Telechat date: 6-November-2008 Summary: This draft is almost ready for publication as Proposed Standard, but I have a few comments. Substantial =========== Section 8.1: Responder identity When Bob does not respond with an UPDATE message, his identity is not integrity protected. The draft states that in such case, a MITM attacker may tamper with the fingerprint but Bob would be aware of this. It is not clear to me how Bob would be aware of this. Consider the scenario where an attacker Eve (who can attack both the signaling and media paths) has switched Bob's key fingerprint with hers. She can receive encrypted media coming from Alice, decrypt it for her own use and re-encrypt it for Bob and send it to him. How will Bob detect this tampering? Minor ===== * draft-ietf-avt-dtls-srtp-05 needs to become a Normative reference instead of an informative reference. Section 6.10 has the following text "Implementations of this specification MUST support DTLS-SRTP" making it impossible to implement this spec without implementing DTLS-SRTP. This will also lead to a downref that needs to be called out. * Section 7: Call flow with STUN "Message (6): STUN connectivity-check response Bob -> Alice" Bob is responding to Message 5 instead of Message 3 as stated in the text. Please replace. Editorial ========= * SBC (expand at first use) : Probably add reference to draft-ietf-sipping-sbc-funcs-07 * Section 6.10: s/less highly optimized/less optimized/ Typos ===== Section 1 Para 4: s/sigaling/signaling/ Section 6.7.2: s/appopriate/appropriate/ Section 6.9 Title: s/Encryptions/Encryption/ Section 7 Para 3: s/especialy/especially/ Section 8.6 para 2: s/taht/that/ Appendix A.3. : s/Reusage/Reuse/ Appendix A.18. : s/Negotation/Negotiation/