Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
draft-ietf-avt-dtls-srtp-07

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-tls-rfc4347-bis, draft-rescorla-tls-suiteb, draft-ietf-tls-extractor, draft-green-secsh-ecc, draft-ietf-avt-dtls-srtp, draft-igoe-secsh-suiteb, draft-ietf-smime-3851bis, draft-ietf-smime-3850bis, dra...

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-smime-3278bis, draft-ietf-smime-sha2, draft-ietf-smime-multisig, draft-ietf-smime-3850bis, draft-ietf-smime-3851bis, draft-igoe-secsh-suiteb, draft-ietf-avt-dtls-srtp, draft-green-secsh-ecc, draft-ie...

[Ballot comment]
Section 4.2, immediately before Figure 1:

A brief statement that the master key and master salt are provided to the SRTCP key
derivation function seems to be missing here.  These invocations are implied by Figure
1, but are conspicuously absent from the text.

[Ballot comment]
Section 3:

"This improves the cryptographic
  performance of DTLS, but may cause problems when RTCP and RTP are
  subject to different network treatment (e.g., for bandwidth
  reservation or scheduling reasons.)"
 
The above sentence seems so backwards. If you multiplex them together then they can't be subject to different treatment. And the reasons seems to be wrong ones for arguing against multiplexing. The three main reasons why RTP and RTCP isn't multiplex as stated in the MUX draft are: Simplicity, effiency and 3rd party monitoring. Especially the last is hard to combine with encryption services, especially such that perform setup point to point.

[Ballot discuss]
Section 4:

I am annoyed that I didn't catch this in my earlier review of this document. I might also be missing some vital piece. However, there seems to be a significant mismatch between this document and the SRTP one. SRTP has crypto contexts that are identied by the triplet: SSRC, destination address and destination port (see section 3.2.1 of RFC 3711). Within each context there might be one or more master keys identified with the MKI if used.

The DTLS-SRTP document seems to fail to take into account that the MKI and creation of crypto context (including the SRTP master keys) needs to be scoped by SSRC. The DTLS-SRTP document correctly discusses the forking issue when multiple DTLS handshake may happen and result in different DTLS contexts all delivering SRTP packets and DTLS messages to the same port. However, within each pairing there are only the DTLS client and the server, but there might be multiple SSRCs for each client and server. This doesn't seem to be covered. This might be a result in the failure to clearly connect the terminology between DTSL and SRTP.

From a crypto context perspective as described in RFC 3711 one should probably discuss this case properly. A modified figure 2 would look like this:

This is the client has two SSRCs X and Y, while the server has two SSRCs Z and W.

    Client          Server                Kontext
    <-------DTLS------>
    ----SRTP SSRC=X--->  src/dst=a/b, uses RTP_client_write_key_X
    ----SRTP SSRC=Y--->  src/dst=a/b, uses RTP_client_write_key_Y
    <---SRTP SSRC=Z----  src/dst=b/a, uses RTP_server_write_key_Z
    <---SRTP SSRC=W----  src/dst=b/a, uses RTP_server_write_key_W

    <-------DTLS------>
    ----SRTCP SSRC=X--->  src/dst=c/d, uses RTCP_client_write_key_X
    ----SRTCP SSRC=Y--->  src/dst=c/d, uses RTCP_client_write_key_Y
    <---SRTCP SSRC=Z----  src/dst=d/c, uses RTCP_server_write_key_Z
    <---SRTCP SSRC=W----  src/dst=d/c, uses RTCP_server_write_key_W
 
So in the above case one has a number of different crypto contexts depending on the SSRC and the destination. However, SRTP seems not to clear that what one does for the existing ciphers is to do the following operation:

Context RTP_client_write_key_X = RTP_client_write_key_Y

Instead one uses the IV for AES-CM to get unique keys for different SSRCs. However, as this is a construct that depends on the cipher I don't think the DTLS specification can assume this to be always true. Thus it should be able to derive different master keys for the different kontexts.

I think we need to clear this up. I know quite a lot of the blame for this can be put on SRTP that doesn't clearly express this relation. I think it is time we do reviese RFC 3711 to make these things clearer.

[Ballot discuss]
Cullen: Who is proposed as the designated expert for the new registry?

RFC 5226 "Specification Required" means a designated expert needs to
be chosen.

Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...

IANA Last Call comments:

[NOTE: This document is dependent on the IANA Actions in the
not-yet-reviewed ietf-tls-extractor document. IANA cannot
complete the actions in this document until ietf-tls-extractor
is acted upon.]

IANA Has Questions:

- The SRTP Protection Profiles table in section 4.1.2 don't match
the list of profiles half a page later. E.g., the table contains
SRTP_AES128_CM_SHA1_80 but the list has SRTP_AES128_CM_HMAC_SHA1_80.
Should these names be reconciled?

Action 1:

Upon approval of this document, the IANA will make the following assignment
in the "ExtensionType Values" registry at
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Value Extension Name Reference
----- ---------------- ------------
[TBD] use_srtp [RFC-avt-dtls-srtp-05]


Action 2:

IANA has questions about this action (see above).

Upon approval of this document, the IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: SRTP Protection Profiles
Registration Procedures: Specification Required
Initial contents of this registry will be:

Number Profile Reference
------ ------- -----------
{0x00, 0x01} SRTP_AES128_CM_SHA1_80 [RFC-avt-dtls-srtp-05]
{0x00, 0x02} SRTP_AES128_CM_SHA1_32 [RFC-avt-dtls-srtp-05]
{0x00, 0x05} SRTP_NULL_SHA1_80 [RFC-avt-dtls-srtp-05]
{0x00, 0x06} SRTP_NULL_SHA1_32 [RFC-avt-dtls-srtp-05]


Action 3:

Upon approval of this document, the IANA will make the following assignments
in the sub-registry "proto" at
http://www.iana.org/assignments/sdp-parameters


Type SDP Name Reference
-------------- --------------------------- ---------
proto
UDP/TLS/RTP/SAVP [RFC-avt-dtls-srtp-05]
DCCP/TLS/RTP/SAVP [RFC-avt-dtls-srtp-05]

UDP/TLS/RTP/SAVPF [RFC-avt-dtls-srtp-05]
DCCP/TLS/RTP/SAVPF [RFC-avt-dtls-srtp-05]


Action 4:

[NOTE: This registry does not yet exist; it is due to be created
by normative reference I-D.ietf-tls-extractor]

Upon approval of this document, the IANA will make the following assignment
in the "TLS Extractor Label" registry located at
http://www.iana.org/assignments/TBD

Value Reference
----- ------------
EXTRACTOR-dtls_srtp [RFC-avt-dtls-srtp-05]


We understand the above to be the only IANA Actions for this document.

(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?

The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.


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

The document went through  two WGLC since there were comments during
The first one. The comments were addressed and there were no further
comments in the second WGLC. The document shepherd has no concerns
about the review process.


(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?

No concerns.


(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 WG has discussed those issues and has
          indicated that it still wishes to advance the document,
          detail those concerns here.  Has an IPR disclosure related to
          this document been filed?  If so, please include a reference
          to the disclosure and summarize the WG discussion and
          conclusion on this issue.

No concerns. There is no disclosed IPR on this document.


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

The document has good consensus from the WG.


(1.f)  Has anyone threatened an appeal or otherwise indicated 
          extreme discontent?  If so, please summarize 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.)

No.


(1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html 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?

The idnits tool reports some warning but they were checked and there
are no issues there.


(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].

References have been split. There are normative references to
internet-drafts which are in progress, There is normative down-
references to draft-ietf-tls-extractor-01 but this is an error in the
tls-extractor and will be fixed in the next revision.


(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 suggest a
          reasonable name for the new registry?  See [RFC2434].  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 IANA considerations section exists, and appears consistent with
this document. The new registry defines the initial values and
procedure to add values.


(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?

OK


(1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

"This document describes a Datagram Transport Layer Security (DTLS)
extension to establish keys for secure RTP (SRTP) and secure RTP
Control Protocol (SRTCP) flows.  DTLS keying happens on the media
path, independent of any out-of-band signalling channel present."

          Working Group Summary

              Was there anything in WG process that is worth noting? 
              For  example, was there controversy about particular
              points or were there decisions where the consensus was
              particularly rough?

There was a discussion about which in band keying mechanism should be
used; it is captured in draft-ietf-sip-media-security-requirements.
There was rough consensus for this solution.

          Document Quality
              Are there existing implementations of the protocol? 
              Have a significant number of vendors indicated their plan
              To implement the specification?  Are there any reviewers
              that merit special mention as having done a thorough
              review, e.g., one that resulted in important changes or a
              conclusion that the document had no substantive 
              issues?  If there was a MIB Doctor, Media Type or other
              expert review, what was its course (briefly)?  In the
              case of a Media Type review, on what date was the request
              posted?

There were indications by vendors that they will implement this
solution.

Pasi Eronen did a good review during the WGLC that helped with
improving of the document. He is mentioned in section 10 of the
document (Acknowledgments)

          Personnel
              Who is the Document Shepherd for this document?  Who is 
              the Responsible Area Director?

Roni Even is the document shepherd.

The responsible area director is Cullen Jennings.