An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)
draft-ietf-sipbrandy-osrtp-10

(1) Section 1.1.  Per “It is only to be used in existing deployments which are attempting to transition to fully secure communications.  New applications and new deployments will not use  OSRTP.”, I was expecting RFC2119 words for the second sentence on the order of “New application … should not …”.

(2) Section 3.1.  Is there any value in creating a registry to manage the possible “a=xxx” offer types?

(3) Editorial Nits:
Section 1.0. Extra space.  s/[RFC5939] ./[RFC5939]./
Section 1.0.  Expand OSRTP acronym on first use.  (done in title and abstract but not in text)
Section 3.  Typo.  s/oportunistic/opportunistic/

I share Mirja's question about the informal status of this document.

If ZRTP is already an OS method, and there are no changes to the ZRTP
usage or security considerations as part of OSRTP, why do we need to
cover ZRTP in this document at all (other than a pointer to "this other
OS mechanism exists")?

I could also see someone subscribing to an "attractive nuisance" theory
that obliges us to put a stronger disclaimer against secdes and/or ZRTP
usage, since we mention them in this document.  Perhaps something about
how they are generally considered to not be reasonable solutions for
"comprehensive protection" solutions but can still be useful in OS
environments?

Abstract

   Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
   implementation of the Opportunistic Security mechanism, as defined in

nit: maybe s/implementation/application/?

Section 1

                                     OSRTP allows SRTP to be negotiated
   with the RTP/AVP profile, with fallback to RTP if SRTP is not
   supported.

nit: Given the preceding context, I don't see a way to read this other
than OSRTP using RTP/AVP and disallowing RTP/AVPF.  I don't know whether
an "RFP/AVP(F)" notation is at all conventional (we do "(D)TLS" and
"(EC)DHE" a lot in the security area) or they would need to both be
written out.

I agree with the directorate reviewer that inlining a substantial
portion of the "motivation and requirements for opportunistic secure
media" from draft-kaplan-mmusic-best-effort-srtp into this document
would be appropriate (while still acknowledging the prior effort).

                                      OSRTP requires no additional
   extensions to SDP or new attributes and is defined independently of
   the key agreement mechanism used.  [...]

The "defined independently" part seems to only mostly be true; see,
e.g., the security considerations where we override the need for
authenticated signaling for DTLS-SRTP OSRTP.


Section 2

Please use the boilerplate from RFC 8174 (in particular, just the "BCP
14 [RFC2119] [RFC8174]" label+references is fine).

Section 3

nit: I think most recent documents going by use "m=" rather than "m-".

   It is important to note that OSRTP makes no changes, and has no
   effect on media sessions in which the offer contains a secure profile

nit: comma after "no effect on" -- the current text is saying that OSRTP
makes no changes at all, globally, without scoping to media sessions in
which the offer contains a secure profile (which I presume to be the
intent).  I think we also need to add "to" in "makes no changes to".

Section 4

   While OSRTP does not require authentication of the key-agreement
   mechanism, it does need to avoid exposing SRTP keys to eavesdroppers,
   since this could enable passive attacks against SRTP.  Section 8.3 of
   [RFC7435] requires that any messages that contain SRTP keys be

As already noted, this is probably supposed to be an RFC 4568 reference.
Yet that is specific to secdes and not a generic SRTP consideration.

   encrypted, and further says that encryption "SHOULD" provide end-to-
   end confidentiality protection if intermediaries that could inspect
   the SDP message are present.  At the time of this writing, it is
   understood that the [RFC7435] requirement for end-to-end
   confidentiality protection is commonly ignored.  Therefore, if OSRTP

As noted, this is not an RFC 7435 requirement, and 4568 seems to be
the most likely interpretation.
FWIW, my reading of 4568 is that it requires end-to-end authentication
as well as confidentiality.  (And yes, we attempt to relax that above.)
Finally, the tsvart reviewer's concerns might be alleviated if we say
"end-to-end (as opposed to just hop-by-hop) confidentiality protection".

Also, it might be nice to give some reference for the "commonly ignored"
statement, if such is readily available.

   is used with SDP Security Descriptions, any such intermediaries
   (e.g., SIP proxies) must be assumed to have access to the SRTP keys.

Given that all of this paragraph (except potentially the first sentence)
seems to be secdes-specific, I'd suggest breaking it out into a new
paragraph and explicitly scoping to RFC 4568, and possibly even using a
subsection to indicate the scope.

Also, we should probably have another sentence or two to mention what
the potential consequences of intermediate access to keys are.

   As discussed in [RFC7435], OSRTP is used in cases where support for
   encryption by the other party is not known in advance, and not
   required.  [...]

nit: 7435 does not discuss OS*RTP*'s use at all.  So some rewording
seems in order, like, "As discussed in [RFC7435], opportunistic
security in general, and thus OSRTP specifically, is used" or "Per the
discussion in [RFC7435], OSRTP is used", etc.

Section 6

   There are implementations of [I-D.kaplan-mmusic-best-effort-srtp] in
   deployed products by Microsoft and Unify.  The IMTC "Best Practices
   for SIP Security" document [IMTC-SIP] recommends this approach.  The
   SIP Forum planned to include support in the SIPconnect 2.0 SIP
   trunking recommendation [SIPCONNECT].  There are many deployments of
   ZRTP [RFC6189].

nit: I know this is to be removed before publication, but "recommends
this approach" is a bit ambiguous about whether the kaplan approach or
this document is being recommended.

Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational decided? As this is a protocol specification, informational does not seem appropriate. Except this is meant to only document an existing deployment but then the document should say so. I think it should rather be experimental.