ZRTP: Media Path Key Agreement for Unicast Secure RTP
draft-zimmermann-avt-zrtp-22

[Ballot comment]
#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 4.4.1.2: 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.

[Ballot discuss]
[Updating to clear addressed DISCUSS positions.]

This is a fine document.  I've got a couple of DISCUSSes:

1) addressed in -22.

As noted in the SECDIR review:

2) addressed in -22.

3) Add some text to explain how the mapping of ZIDs to AORs works.

4) addressed in -22.

[Ballot comment]
#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 4.4.1.2: 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.

[Ballot discuss]
[I've updated these to provide more information at the AD's request.]

This is a fine document.  I've got a couple of DISCUSSes:

1) Because NIST hasn't indicated that the protocol is in compliance with a various FIPS/SPs (normally done through some kind of testing regime), I believe that "compliance" statements are made by the authors and should be clearly stated as such.  What I'd like to see is something along the lines of:

The authors believe, the calculation of the final shared secret, s0, is in compliance with the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A [SP800-56A].

and

The authors believe, ZRTP DH mode is in full compliance with two relevant NIST documents that cover key derivations.

and

For ECDH mode the authors believe, the s0 calculation is also in compliance with section
  3.1 of NSA's Suite B Implementer's Guide to NIST SP 800-56A
  [NSA-Suite-B-Guide-56A].

(in 4.5.1)

The authors believe, the ZRTP KDF is in full compliance with the recommendations in NIST
  SP 800-108 [SP800-108].

(in 14)

To meet the FIPS-140 validation requirements
set by NIST FIPS PUB 140-2 Annex A [FIPS-140-2-Annex-A] and NIST
FIPS PUB 140-2 Annex D [FIPS-140-2-Annex-D], the authors believe ZRTP is compliant
with NIST SP 800-56A [SP800-56A], NIST SP 800-108 [SP800-108],
NIST FIPS PUB 198-1 [FIPS-198-1], NIST FIPS PUB 180-3
[FIPS-180-3], NIST SP 800-38A [SP800-38A], NIST FIPS PUB 197
[FIPS-197], and NSA Suite B [NSA-Suite-B].

As noted in the SECDIR review:

2) Some discussion about PMTU discovery is needed because it appears that the signature block can exceed common PMTUs.  It's quite common for firewalls and NATs to simply block all fragmented packets.  If you are behind such a network element, then retransmits will not help, they'll just be dropped as well.

What I think we're looking for is some text that says when these types of boxes get fragmented code that the connection is going to be dropped.

3) Add some text to explain how the mapping of ZIDs to AORs works.

4) The SAS security considerations need to be expanded.  Awaiting responses from the authors.

[Ballot comment]
(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.

[Ballot discuss]
[Revised for clarity at teh request of the sponsoring AD]

A very thorough piece of work.  I enjoyed reviewing this one, and
look forward to clearing my discuss quickly so this can be published!
However, there are a couple of issues I would like to see addressed...

(1) As noted in the abstract, ZRTP can be used to secure mdia sessions
that don't include voice by using the optional digital signatures. IMHO,
this merits a brief subsection in the security considerations.  In particular, I would like to see text indicating that support for the optional digital signatures is required to safely apply ZRTP in these
applications.

The specification defines two different formats for signatures without
indicating a preference.  To support interoperability, any protocol that
does not include voice traffic and specifies ZRTP to protect media will
need to select a mandatory-to-implement format (X.509 or PGP).  This
should also be entioned in the new security considerations section.

(2) I also think that a brief section on intermediary devices that act as
ZRTP endpoints (as described in section 10, paragraph 3) would be a good
addition to the security considerations.

[Ballot discuss]
This is a discuss-discuss, based on feedback from Colin Perkins during  TSV-DIR review:
"I've sent various comments regarding draft-zimmermann-avt-zrtp, most 
recently on 14 May 2010 (to ietf@ietf.org and the AVT working group). 
While there are no fundamental problems with the draft, I do believe 
there are some issues that should be addressed before it becomes an 
RFC. Most important of the remaining transport-related issues are 
handling of RTP SSRC collisions, incompatibility with RFC 5285, and 
timer values for non-UDP transports."

[Ballot discuss]
This is a discuss-discuss, based on feedback from Colin Perkins during  TSV-DIR review:
I've sent various comments regarding draft-zimmermann-avt-zrtp, most 
recently on 14 May 2010 (to ietf@ietf.org and the AVT working group). 
While there are no fundamental problems with the draft, I do believe 
there are some issues that should be addressed before it becomes an 
RFC. Most important of the remaining transport-related issues are 
handling of RTP SSRC collisions, incompatibility with RFC 5285, and 
timer values for non-UDP transports.

[Ballot comment]
#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 4.4.1.2: 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.

[Ballot discuss]
This is a fine document.  I've got a couple of DISCUSSes:

1) This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do):

(Sec 4.4.1.4) Is it appropriate to claim compliance to NIST documents?

As noted in the SECDIR review:

2) Some discussion about PMTU discovery is needed because it appears that the signature block can exceed common PMTUs.  It's quite common for firewalls and NATs to simply block all fragmented packets.  If you are behind such a network element, then retransmits will not help, they'll just be dropped as well.

3) Add some text to explain how the mapping of ZIDs to AORs works.

4) The SAS security considerations need to be expanded.  Awaiting responses from the authors.

[Ballot comment]
#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 4.4.1.2: 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.

[Ballot discuss]
This is a fine document.  I've got a couple of DISCUSSes:

1) This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do):

(Sec 4.4.1.4) Is it appropriate to claim compliance to NIST documents?

As noted in the SECDIR review:

2) Some discussion about PMTU discovery is needed because it appears that the signature block can exceed common PMTUs.  It's quite common for firewalls and NATs to simply block all fragmented packets.  If you are behind such a network element, then retransmits will not help, they'll just be dropped as well.

3) Add some text to explain how the mapping of ZIDs to AORs works.

4) The SAS security considerations need to be expanded.  Awaiting responses from the authors.

[Ballot comment]
#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 4.4.1.2: 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.

[Ballot discuss]
This is a fine document.  I've got a couple of DISCUSSes:

1) This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do):

(Sec 4.4.1.4) Is it appropriate to claim compliance to NIST documents?

As noted in the SECDIR review:

2) Some discussion about PMTU discovery is needed because it appears that the signature block can exceed common PMTUs.  It's quite common for firewalls and NATs to simply block all fragmented packets.  If you are behind such a network element, then retransmits will not help, they'll just be dropped as well.

3) Add some text to explain how the mapping of ZIDs to AORs works.

4) The reviewer pointed out that he felt the SAS security considerations need to be expanded.  Awaiting responses from the authors.

[Ballot discuss]
As noted in the SECDIR review:

1) Some discussion about PMTU discovery is needed because it appears that the signature block can exceed common PMTUs.  It's quite common for firewalls and NATs to simply block all fragmented packets.  If you are behind such a network element, then retransmits will not help, they'll just be dropped as well.

2) Add some text to explain how the mapping of ZIDs to AORs works.

3) The SAS security considerations need to be augmented.  There is some disagreement wrt

[Ballot comment]
(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.

[Ballot discuss]
A very thorough piece of work.  I enjoyed reviewing this one, and
look forward to clearing my discuss quickly so this can be published!
However, there are a couple of issues I would like to see addressed...

(1) As noted in the abstract, ZRTP can be used to secure mdia sessions
that don't include voice by using the optional digital signatures. IMHO,
this merits a brief subsection in the security considerations.  I
believe that support for digital signatures should be mandatory for ZRTP
in such applications.

To support interoperability in this case, it would be helpful to select
a mandatory-to-implement format (X.509 or PGP).

(2) I also think that a brief section on intermediary devices that act as
ZRTP endpoints (as described in section 10, paragraph 3) would be a good
addition to the security considerations.

[Ballot comment]
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.

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 coment on 4.2)

3.1.3, first sentence
s/and hence/with/
rationale: established SRTP media stream does not imply a ZRTP
session key in many contexts


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.  Am I missing
something?

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.

[Ballot discuss]
A very thorough piece of work.  I enjoyed reviewing this one, and
look forward to clearing my discuss quickly so this can be published!
However, there are a couple of issues I would like to see addressed...

(1) As noted in the abstract, ZRTP can be used to secure mdia sessions
that don't include voice by using the optional digital signatures. IMHO,
this merits a brief subsection in the security considerations.  I
believe that support for digital signatures should be mandatory for ZRTP
in such applications.

To support interoperability in this case, it would be helpful to select
a mandatory-to-implement format (X.509 or PGP).

(2) I also think that a brief section on intermediary devices that act as
ZRTP endpoints (as described in section 10, paragraph 3) would be a good
addition to the security considerations.

[Ballot comment]
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?

[Ballot comment]
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).

[Ballot comment]
The Gen-ART Review by Pete McCann on 17-May-2010 raised a question:
  >
  > I see that in draft-19, a change was made to stop using the term
  > "HMAC" and instead substitute "MAC".  However, in several places,
  > the term "keyed hash" seems to be used interchangeably with the
  > term "MAC".  Is a MAC always a "keyed hash"?
  >
  One author said:
  >
  > Thank you for pointing out that spot. It might be a glitch. We'll
  > look at it.
  >
  Please make sure that this comment is considered.

IANA questions/comments:

QUESTIONS:

- Do you want to create registries for Message Types, Hash Types,
Cipher Types, Auth Tag Types, Key Agreement Types, SAS Types,
or Signature Types?

- Do you want to create a registry for Error Codes?

Upon approval of this document, IANA will make the following assignment
in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
zrtp-hash [RFC-zimmermann-avt-zrtp-17]

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

        Robert Sparks is the document shepherd and responsible AD. I have
        personally reviewed this document and believe it ready for
        forwarding to the IESG for publication as Informational.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

        Previous versions of this document have received widespread review
        as part of the rtpsec bof and in the avt working groups. 
        I do not have concerns with the depth/breadth of review for
        publication as Informational.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

        This document is normatively referencing draft-ietf-avt-srtp-big-aes.
        I have heard some comments questioning the need for that document
        at this time - I would like the security ADs to note/comment on
        this aspect of the document.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

        See 1.c

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

        There was a consensus to choose another solution for keying
        SRTP as Proposed Standard (dtls-srtp). See the proceedings at
        .


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        There have been no threats of appeal.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

        Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

        The document has an appropriate split. See 1.c. There are no downrefs.
        is listed as a
        normative reference.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

        The actions for IANA are clear and complete.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

        I have relied on the document's authors statements and visual scans
        that the short chunk of BNF in the document (copied here) validates:

          zrtp-attribute  = "a=zrtp-hash:" zrtp-version zrtp-hash-value
          zrtp-version    = token
          zrtp-hash-value  = 1*(HEXDIG)

  (1.k) Document Announcement Write-Ups

    Technical Summary

    This document defines ZRTP, a protocol for media path Diffie-Hellman
    exchange to agree on a session key and parameters for establishing
    Secure Real-time Transport Protocol (SRTP) sessions for VoIP
    applications.  The ZRTP protocol is media path keying because it is
    multiplexed on the same port as RTP and does not require support in
    the signaling protocol.  ZRTP does not assume a Public Key
    Infrastructure (PKI) or require the complexity of certificates in end
    devices.  For the media session, ZRTP provides confidentiality,
    protection against man-in-the-middle (MiTM) attacks, and, in cases
    where the signaling protocol provides end-to-end integrity
    protection, authentication.  ZRTP can utilize a Session Description
    Protocol (SDP) attribute to provide discovery and authentication
    through the signaling channel.  To provide best effort SRTP, ZRTP
    utilizes normal RTP/AVP profiles.  ZRTP secures media sessions which
    include a voice media stream, and can also secure media sessions
    which do not include voice by using an optional digital signature.

    IETF Discussion Summary

    This protocol was proposed as a solution for keying SRTP and received
    significant review and discussion while it was being considered. The
    IETF chose a different proposal (draft-ietf-avt-dtls-srtp) to publish
    as Proposed Standard.

    Document Quality   

    There are multiple implementations of this protocol.
    A reference implementation of ZRTP is available as Zfone.