ZRTP: Media Path Key Agreement for Unicast Secure RTP
Note: This ballot was opened for revision 22 and is now closed.
(Robert Sparks) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Adrian Farrel) No Objection
Comment (2010-06-03 for -)
I think it would be tidier to move the Appendix (currently Section 14) to the end of the document. --- Can I assume that a deliberate and careful decision has been made not to create IANA registries to manage the codepoint spaces defined in this document?
(David Harrington) (was Discuss) No Objection
(Russ Housley) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
(a) Section 3 could be interpreted as requiring a single Hello-HelloACK exchange. A few pages later, it becomes clear that both the initiator and responder are required to generate a Hello and respond with a HelloACK. I would suggest a few clraifying words in section 3. (b) In section 3.1.1, I gather that the initiator needs to generate their ephemeral key pair before sending the Commit, and the responder generates their key pair before sending DHPart1. It might be helpful to add that information - it helps clarify issues regarding Commit contention. (see comment on 4.2) (c) this is a nit, but 3.1.3, first sentence s/and hence/with/ rationale: established SRTP media stream does not imply a ZRTP session key in many contexts (d) 4.2 last paragraph As I understand it, if commit contention occurs, both parties will generate ephemeral key pairs before genreating the commit. The point of this paragraph is that a new key pair does not need to be generated by the entity that is selected to be responder by the contention resolution process. If that is correct, this bit could be a bit clearer. However, this text states "should only be discarded if it does not match the initiator's key size". As I understood the algorithm negotiation process, I do not believe this condition can ever occur with two well-behaved systems. Am I missing something? Wouldn't this indicate an attack? (e) Section 7.2.1 establishes clear constraints on the algorithms and key sizes. Section 7.2.2 implies that X.509 certificates are restricted to EC P-256 and P-384 keys. Is this intentional? Other algorithms could have issues with the 2044 octet limitation for the X509 signature block, but it is certainly possible to support effective DSA and RSA key sizes within that limitation. Given that the vast maority of X.509 cetificates contain RSA keys, limiting ZRTP to ECDSA would seem to be a major ipediment to using this feature.
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2010-06-02 for -)
Please check the division of references into normative and informative. For example, I doubt that [XEP-0262] is a normative reference (because developers don't need to understand XEP-0262 in order to implement ZRTP).
(Sean Turner) (was Discuss) No Objection
#1) Sec 4.1.1: Should the should be SHOULD: Both parties should choose the highest version number that appear in both parties' list of a=zrtp-hash version numbers, and use that version for their Hello messages. #2) Sec 22.214.171.124: Should the should be SHOULD: If pvi is 1 or p-1, the user should be alerted of the attack and the protocol exchange MUST be terminated. #3) Is the space really used: clear_mac = MAC(mackeyi, "GoClear ") #4) I support Tim's DISCUSSes.